[PATCH] D30590: Don't assume cleanup emission preserves dominance in expr evaluation

[Reid Kleckner via Phabricator via cfe-commits]

rnk created this revision.

Because of the existence branches out of GNU statement expressions, it
is possible that emitting cleanups for a full expression may cause the
new insertion point to not be dominated by the result of the inner
expression. Consider this example:

  struct Foo { Foo(); ~Foo(); int x; };
  int g(Foo, int);
  int f(bool cond) {
    int n = g(Foo(), ({ if (cond) return 0; 42; }));
    return n;
  }

Before this change, result of the call to 'g' did not dominate its use
in the store to 'n'. The early return exit from the statement expression
branches to a shared cleanup block, which ends in a switch between the
fallthrough destination (the assignment to 'n') or the function exit
block.

This change solves the problem by spilling and reloading expression
evaluation results when any of the active cleanups have branches.

I audited the other call sites of enterFullExpression, and they don't
appear to keep and Values live across the site of the cleanup, except in
ARC code. I wasn't able to create a test case for ARC that exhibits this
problem, though.


https://reviews.llvm.org/D30590

Files:
  lib/CodeGen/CGCleanup.cpp
  lib/CodeGen/CGExprComplex.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CodeGenFunction.h
  test/CodeGenCXX/stmtexpr.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D30590.90528.patch
Type: text/x-patch
Size: 12339 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170303/c70b7cc5/attachment-0001.bin>