Commit Graph

9 Commits

Author SHA1 Message Date
Reid Kleckner 0449316ea0 Don't try to spill static allocas when emitting expr cleanups with branches
Credit goes to Gor Nishanov for putting together the fix in
https://reviews.llvm.org/D33733!

This patch is essentially me patching it locally and writing some test
cases to convince myself that it was necessary for GNU statement
expressions with branches as well as coroutines. I'll ask Gor to land
his patch with just the coroutines test.

During LValue expression evaluation, references can be bound to
anything, really: call results, aggregate temporaries, local variables,
global variables, or indirect arguments. We really only want to spill
instructions that were emitted as part of expression evaluation, and
static allocas are not that.

llvm-svn: 304335
2017-05-31 19:59:41 +00:00
Reid Kleckner ef23e9574e Relax stmtexpr.cpp checks for PPC64
llvm-svn: 297099
2017-03-06 23:49:18 +00:00
Reid Kleckner 092d065265 Don't assume cleanup emission preserves dominance in expr evaluation
Summary:
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.

Reviewers: rjmccall, rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D30590

llvm-svn: 297084
2017-03-06 22:18:34 +00:00
Hans Wennborg c9bd88e681 Remove the -cxx-abi command-line flag.
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.

To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.

Differential Revision: http://llvm-reviews.chandlerc.com/D2545

llvm-svn: 199250
2014-01-14 19:35:09 +00:00
Hans Wennborg 442e4f7f5f Prepare for using MS ABI by default for Win32: update CodeGenCXX tests
llvm-svn: 197281
2013-12-13 22:43:52 +00:00
Eli Friedman 4871a46cc3 Make sure we don't emit invalid IR for StmtExprs with complex cleanups.
Fixes <rdar://problem/14074868>.

llvm-svn: 183699
2013-06-10 22:04:49 +00:00
Eli Friedman 50ed150632 Whack a bunch of tests in CodeGenCXX to work on ARM (using ARM ABI). Batch 2 of 3.
llvm-svn: 133011
2011-06-14 21:20:53 +00:00
Fariborz Jahanian 5701585780 patch to do array-to-pointer conversion in a
statement-expression. // rdar: //8600553

llvm-svn: 117479
2010-10-27 20:10:28 +00:00
Fariborz Jahanian 56143ae715 Patch for mis-compile of statement expressions with
non-trivial copy constructors. // rdar: //8540501.
A test will be added to llvm nightly tests.

llvm-svn: 117324
2010-10-25 23:27:26 +00:00