__cxxabiv1::__fundamental_type_info in every translation
unit. Previously, we would perform name lookup for
__cxxabiv1::__fundamental_type_info at the end of IRGen for a each
translation unit, to determine whether it was present. If so, we we
produce type information for all of the fundamental types. However,
this name lookup causes PCH deserialization of a significant part of the
translation unit, which has a woeful impact on performance.
With this change, we now look at each record type after we've
generated its vtable to see if it is
__cxxabiv1::__fundamental_type_info. If so, we generate type info for
all of the fundamental types. This works because
__cxxabiv1::__fundamental_type_info should always have a key function
(typically the virtual destructor), that will be defined once in the
support library. The fundamental type information will end up there.
Fixes <rdar://problem/7840011>.
llvm-svn: 100772
assembly for the global "d7". We were previously testing for alignment
3, which seems to happen for some builders and not for others. I've
eliminated the alignment check and added a FIXME to unbreak the
buildbots.
llvm-svn: 100205
poor (and wrong) approximation of the actual rules governing when to
build a copy and when it can be elided.
The correct implementation is actually simpler than the
approximation. When we only enumerate constructors as part of
initialization (e.g., for direct initialization or when we're copying
from a class type or one of its derived classes), we don't create a
copy. When we enumerate all conversion functions, we do create a
copy. Before, we created some extra copies and missed some
others. The new test copy-initialization.cpp shows a case where we
missed creating a (required, non-elidable) copy as part of a
user-defined conversion, which resulted in a miscompile. This commit
also fixes PR6757, where the missing copy made us reject well-formed
code in the ternary operator.
This commit also cleans up our handling of copy elision in the case
where we create an extra copy of a temporary object, which became
necessary now that we produce the right copies. The code that seeks to
find the temporary object being copied has moved into
Expr::getTemporaryObject(); it used to have two different
not-quite-the-same implementations, one in Sema and one in CodeGen.
Note that we still do not attempt to perform the named return value
optimization, so we miss copy elisions for return values and throw
expressions.
llvm-svn: 100196
the existing (and already well-tested) linkage computation for types,
with minor tweaks for dynamic classes and (pointers to) incomplete
types. Fixes PR6597.
llvm-svn: 99968
through the bases and fields of the definition of the class in which
the constructor is declared, rather than some other declaration of
that class.
llvm-svn: 99661
EmitReferenceBindingToExpr() rather than assuming we have an
lvalue. This is just the lowest hanging fruit for PR6024, which still
requires a bit of work.
llvm-svn: 99447
implicit methods on explicit template instantiation definitions. As a
consequence, we should emit them at every use, even if we see a explicit
template instantiation declaration.
This is already the current behaviour, but it is good to test for that :-)
llvm-svn: 99443
CXXExprWithTemporaries.
Not emitting the expression as an aggregate might be the right thing to do,
but is orthogonal. Emitting it as an scalar expression will still try to
create a temporary for the incomplete type of the CXXExprWithTemporaries and
fail.
llvm-svn: 99134
shadowing it in the GlobalDeclMap. Eliminates the string-uniquing
requirement for mangled names, which should help C++ codegen times a little.
Forces us to do string lookups instead of pointer lookups, which might hurt
codegen times a little across the board. We'll see how it plays out.
Removing the string-uniquing requirement implicitly fixes any bugs like
PR6635 which arose from the fact that we had multiple uniquing tables for
different kinds of identifiers.
llvm-svn: 99012
iterations of this patch gave explicit template instantiation
link-once ODR linkage, which permitted the back end to eliminate
unused symbols. Weak ODR linkage still requires the symbols to be
generated.
llvm-svn: 98441
uninitialized. This seems not to be the case in C++0x, where we still
call the (trivial) default constructor for a POD class
(!). Previously, we had implemented only the C++0x rules; now we
implement both. Fixes PR6536.
llvm-svn: 97928
doesn't do this on any of the major platforms, and we don't really
support any of the platforms that do (nor will we actually handle
those headers well). Fixes PR6217; see PR6530 for details on what we
would need to do to support these platforms.
llvm-svn: 97899
category. Use this in a few places to eliminate unnecessary TST cases and
do some future-proofing. Provide terrible manglings for typeof. Mangle
decltype with some hope of accuracy.
Our manglings for some of the cases covered in the testcase are different
from gcc's, which I've raised as an issue with the ABI list.
llvm-svn: 97523
1) emit base destructors as aliases to their unique base class destructors
under some careful conditions. This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.
2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor. This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).
These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.
llvm-svn: 96842
Fix some bugs with function-try-blocks and simplify normal try-block
code generation.
This implementation excludes a deleting destructor's call to
operator delete() from the function-try-block, which I believe
is correct but which I can't find straightforward support for at
a moment's glance.
llvm-svn: 96670
calling them as subroutines. This triggers whenever the alias optimization
doesn't, i.e. when the dtor has linkonce linkage or there are virtual bases
or it's the deleting dtor.
llvm-svn: 96605
and destructors when the two entities are semantically identical, i.e. when
the class has no virtual base classes. We only do this for linkage types
for which aliases are supported, i.e. internal and external, i.e. not linkonce.
llvm-svn: 96451
Douglas Gregor