right for anonymous struct/union members led to me discovering some
seemingly broken code in that area of Sema, which I fixed, partly by
changing the representation of member pointer constants so that
IndirectFieldDecls aren't expanded. This led to assorted cleanups with
member pointers in CodeGen, and while I was doing that I saw some random
other things to clean up.
llvm-svn: 124785
is not defined in the current translation unit. Doing so lead to compile errors
such as PR9114.
Instead, when CodeGen is building the vtable, don't try to emit a definition
for functions that aren't marked used in the current translation unit.
Fixes PR9114.
llvm-svn: 124768
* llvm-link would complains about mismatched visibility
* If we produce a relocation with an available_externally, it is good to know that
it is hidden.
llvm-svn: 124633
current translation unit as available_externally.
This helps devirtualize the second example in PR3100, comment 18:
struct S { S() {}; virtual void xyzzy(); };
inline void foo(S *s) { s->xyzzy(); }
void bar() { S s; foo(&s); }
This involved four major changes:
1. In DefineUsedVTables, always mark virtual member functions as referenced for
non-template classes and class template specializations.
2. In CodeGenVTables::ShouldEmitVTableInThisTU return true if optimizations are
enabled, even if the key function is not implemented in this translation
unit. We don't ever do this for code compiled with -fapple-kext, because we
don't ever want to devirtualize virtual member function calls in that case.
3. Give the correct linkage for vtables where the key function is not defined.
4. Update the linkage for RTTI structures when necessary.
llvm-svn: 124565
fixing a crash which probably nobody was ever going to see. In doing so,
fix a horrendous number of problems with the conditional-cleanups code.
Also, make conditional cleanups re-use the cleanup's activation variable,
which avoids some unfortunate repetitiveness.
llvm-svn: 124481
non-class prvalues actually require the realization of a
temporary. For everything else, we already have an lvalue (or class
prvalue) in the subexpression.
Note: we're missing some move elision in this case. I'll tackle that next.
llvm-svn: 124453
deallocation function has a two-argument form. Store the result of this
check in new[] and delete[] nodes.
Fixes rdar://problem/8913519
llvm-svn: 124373
I'm separately committing this because it incidentally changes some
block orderings and minor IR issues, like using a phi instead of
an unnecessary alloca.
llvm-svn: 124277