Commit Graph

12 Commits

Author SHA1 Message Date
Douglas Gregor 3a08c1cd3b Two minor, related fixes for template instantiation with blocks:
- Make sure that the block expression is instantiation-dependent if the
    block is in a dependent context
  - Make sure that the C++ 'this' expression gets captured even if we
  don't rebuild the AST node during template instantiation. This would
  also have manifested as a bug for lambdas.

Fixes <rdar://problem/10832617>.

llvm-svn: 151372
2012-02-24 17:41:38 +00:00
Richard Smith dafff94759 constexpr irgen: Add irgen support for APValue::Struct, APValue::Union,
APValue::Array and APValue::MemberPointer. All APValue values can now be emitted
as constants.

Add new CGCXXABI entry point for emitting an APValue MemberPointer. The other
entrypoints dealing with constant member pointers are no longer necessary and
will be removed in a later change.

Switch codegen from using EvaluateAsRValue/EvaluateAsLValue to
VarDecl::evaluateValue. This performs caching and deals with the nasty cases in
C++11 where a non-const object's initializer can refer indirectly to
previously-initialized fields within the same object.

Building the intermediate APValue object incurs a measurable performance hit on
pathological testcases with huge initializer lists, so we continue to build IR
directly from the Expr nodes for array and record types outside of C++11.

llvm-svn: 148178
2012-01-14 04:30:29 +00:00
John McCall f1a3c2aee1 Be sure to insulate block literals from any cleanups in their
enclosing full-expressions.  It is somewhat amazing that 
this hasn't come up as a problem before.

llvm-svn: 144362
2011-11-11 03:19:12 +00:00
John McCall f4beacd059 Whenever explicitly activating or deactivating a cleanup, we
need to provide a 'dominating IP' which is guaranteed to
dominate the (de)activation point but which cannot be avoided
along any execution path from the (de)activation point to
the push-point of the cleanup.  Using the entry block is
bad mojo.

llvm-svn: 144276
2011-11-10 10:43:54 +00:00
John McCall e63abb5d2b Fix a subtle bug with cleanups: when activating
a previously-inactive cleanup, not only do we need a
flag variable, but we should also force the cleanup to
query the flag variable.  However, we only need to do
this when we're activating in a context that's
conditionally executed;  otherwise, we may safely
assume that the cleanup is dominated by the activation
point.

llvm-svn: 144271
2011-11-10 09:22:44 +00:00
John McCall 7d92c70e6f Somehow I fouled up this test.
llvm-svn: 137882
2011-08-17 22:04:02 +00:00
John McCall 75f92b519c Gather cleanups correctly in block return statements.
Thanks to Ted for finding this with magic tools.

llvm-svn: 137877
2011-08-17 21:34:14 +00:00
Chris Lattner a5f58b05e8 clang side to match the LLVM IR type system rewrite patch.
llvm-svn: 134831
2011-07-09 17:41:47 +00:00
John McCall a85af56e66 When block-capturing a variable with a non-trivial destructor,
make sure to mark the destructor.  This normally isn't required,
because the destructor should have been marked as part of the
declaration of the local, but it's necessary when the variable
is a parameter because it's the call sites that are responsible
for those destructors.

llvm-svn: 130372
2011-04-28 02:15:35 +00:00
John McCall f9b056b002 After much contemplation, I've decided that we probably shouldn't "unique"
__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.

Found by inspection.

Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.

llvm-svn: 128618
2011-03-31 08:03:29 +00:00
John McCall b0a3ecb41c Extend the const capture optimization to C++ record types with no
mutable fields and with trivial destructors and copy constructors.

llvm-svn: 125073
2011-02-08 03:07:00 +00:00
John McCall 93be3f75cc When copy-capturing values for a nested capture, use a BlockDeclRefExpr.
llvm-svn: 125021
2011-02-07 18:37:40 +00:00