Commit Graph

14 Commits

Author SHA1 Message Date
Sean Fertile d900dd0c23 Revert "[CodeGenCXX] Treat 'this' as noalias in constructors"
This reverts commit https://reviews.llvm.org/rL344150 which causes
MachineOutliner related failures on the ppc64le multistage buildbot.

llvm-svn: 344526
2018-10-15 15:43:00 +00:00
Anton Bikineev cc7e74753a [CodeGenCXX] Treat 'this' as noalias in constructors
This is currently a clang extension and a resolution
of the defect report in the C++ Standard.

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

llvm-svn: 344150
2018-10-10 16:14:51 +00:00
Richard Smith 30e304e2a6 Remove custom handling of array copies in lambda by-value array capture and
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.

This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.

llvm-svn: 289618
2016-12-14 00:03:17 +00:00
Hal Finkel a2347baaec 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.

llvm-svn: 213386
2014-07-18 15:52:10 +00:00
Nick Lewycky 9b46eb8112 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.
llvm-svn: 209723
2014-05-28 09:56:42 +00:00
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Lang Hames bf122744e5 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.

llvm-svn: 175389
2013-02-17 07:22:09 +00:00
Lang Hames 697b004219 Backing out r174919 while I investigate a self-host bug on Takumi's builder.
llvm-svn: 174925
2013-02-12 00:44:43 +00:00
Lang Hames 5824a4f1b0 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.

llvm-svn: 174919
2013-02-11 23:44:11 +00:00
Richard Smith 993f25a2f9 When deciding whether to convert an array construction loop into a memcpy, look
at whether the *selected* constructor would be trivial rather than considering
whether the array's element type has *any* non-trivial constructors of the
relevant kind.

llvm-svn: 167562
2012-11-07 23:56:21 +00:00
John McCall 1b1a1dbbe7 When synthesizing implicit copy/move constructors and copy/move assignment
operators, don't make an initializer or sub-operation for zero-width
bitfields.

llvm-svn: 133221
2011-06-17 00:18:42 +00:00
Rafael Espindola 05842dabb8 Move unnamed_addr after the function arguments on Sabre's request.
llvm-svn: 124210
2011-01-25 19:10:24 +00:00
Rafael Espindola 0ee986c1f1 Add unnamed_addr to constructors and destructors.
llvm-svn: 123197
2011-01-11 00:26:26 +00:00
Douglas Gregor 94f9a4820a Reimplement code generation for copying fields in the
implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.

The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.

However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:

  struct A { A(const A&); };
  
  struct B {
    A array[2][3];
  };

then we generate an implicit copy assignment operator for B that looks
something like this:

  B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }

CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.

Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.

Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.

llvm-svn: 103079
2010-05-05 05:51:00 +00:00