Commit Graph

8 Commits

Author SHA1 Message Date
Hal Finkel 4cdf252c12 Mark C++ reference parameters as dereferenceable
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.

Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213386 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 15:52:10 +00:00
Nick Lewycky 9e97cc3391 Add 'nonnull' parameter or return attribute when producing an llvm pointer type in a function type where the C++ type is a reference. Update the tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209723 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-28 09:56:42 +00:00
Stephen Lin 93ab6bf534 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188447 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-15 06:47:53 +00:00
Lang Hames 56c00c4868 Re-apply r174919 - smarter copy/move assignment/construction, with fixes for
bitfield related issues.

The original commit broke Takumi's builder. The bug was caused by bitfield sizes
being determined by their underlying type, rather than the field info. A similar
issue with bitfield alignments showed up on closer testing. Both have been fixed
in this patch.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175389 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-17 07:22:09 +00:00
Lang Hames c2808e705e Backing out r174919 while I investigate a self-host bug on Takumi's builder.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174925 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-12 00:44:43 +00:00
Lang Hames 5310859d0d When generating IR for default copy-constructors, copy-assignment operators,
move-constructors and move-assignment operators, use memcpy to copy adjacent
POD members.

Previously, classes with one or more Non-POD members would fall back on
element-wise copies for all members, including POD members. This often
generated a lot of IR. Without padding metadata, it wasn't often possible
for the LLVM optimizers to turn the element-wise copies into a memcpy.

This code hasn't yet received any serious tuning. I didn't see any serious
regressions on a self-hosted clang build, or any of the nightly tests, but
I think it's important to get this out in the wild to get more testing.
Insights, feedback and comments welcome.

Many thanks to David Blaikie, Richard Smith, and especially John McCall for
their help and feedback on this work.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174919 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-11 23:44:11 +00:00
Douglas Gregor 7362258bb8 Try to unbreak clang-i686-darawin10 builder
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102920 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-03 15:51:04 +00:00
Douglas Gregor 06a9f3680d Complete reimplementation of the synthesis for implicitly-defined copy
assignment operators. 

Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.

This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:

  - For a class subobject, call the appropriate copy-assignment
    operator, after overload resolution has determined what that is.
  - For an array of scalar types or an array of class types that have
    trivial copy assignment operators, construct a call to
    __builtin_memcpy.
  - For an array of class types with non-trivial copy assignment
    operators, synthesize a (possibly nested!) for loop whose inner
    statement calls the copy constructor.
  - For a scalar type, use built-in assignment.

This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.

Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102853 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-01 20:49:11 +00:00