[CodeGen] Use ABI alignment for C++ new expressions

In case of placement new, if we do not know the alignment of the
operand, we can't assume it has the preferred alignment. It might be
e.g. a point

[CodeGen] Use ABI alignment for C++ new expressions

In case of placement new, if we do not know the alignment of the
operand, we can't assume it has the preferred alignment. It might be
e.g. a pointer to a struct member which follows ABI alignment rules.

This makes UBSAN no longer report "constructor call on misaligned
address" when constructing a double into a struct field of type double
on i686. The psABI specifies an alignment of 4 bytes, but the preferred
alignment used by Clang is 8 bytes.

We now use ABI alignment for allocating new as well, as the preferred
alignment should be used for over-aligning e.g. local variables, which
isn't relevant for ABI code dealing with operator new. AFAICT there
wouldn't be problems either way though.

Fixes #54845.

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

show more ...

[clang] Remove Address::deprecated() call in CGExprCXX.cpp

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While d

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While doing the rename, I've filled in element types in cases
where it was relatively obvious, but we're still left with 135
calls to the deprecated constructor.

show more ...

[CGBuilder] Remove CreateBitCast() method

Use CreateElementBitCast() instead, or don't work on Address
where not necessary.

[NFC][Clang][OpaquePtr] Move away from deprecated Address constructor in EmitNewArrayInitializer()

Specify the Address element type, which is the same for all pointers in the array.

[CodeGen] Use CreateConstInBoundsGEP() in one more place

This does exactly what this code manually implemented.

[CodeGen] Accept Address in CreateLaunderInvariantGroup

Add an overload that accepts and returns an Address, as we
generally just want to replace the pointer with a laundered one,
while retaining re

[CodeGen] Accept Address in CreateLaunderInvariantGroup

Add an overload that accepts and returns an Address, as we
generally just want to replace the pointer with a laundered one,
while retaining remaining information.

show more ...

[CodeGen] Avoid some pointer element type accesses

This avoids some pointer element type accesses when compiling
C++ code.

[CodeGen] Prefer CreateElementBitCast() where possible

CreateElementBitCast() can preserve the pointer element type in
the presence of opaque pointers, so use it in place of CreateBitCast()
in some

[CodeGen] Prefer CreateElementBitCast() where possible

CreateElementBitCast() can preserve the pointer element type in
the presence of opaque pointers, so use it in place of CreateBitCast()
in some places. This also sometimes simplifies the code a bit.

show more ...

[clang] don't mark as Elidable CXXConstruct expressions used in NRVO

See PR51862.

The consumers of the Elidable flag in CXXConstructExpr assume that
an elidable construction just goes through a sin

[clang] don't mark as Elidable CXXConstruct expressions used in NRVO

See PR51862.

The consumers of the Elidable flag in CXXConstructExpr assume that
an elidable construction just goes through a single copy/move construction,
so that the source object is immediately passed as an argument and is the same
type as the parameter itself.

With the implementation of P2266 and after some adjustments to the
implementation of P1825, we started (correctly, as per standard)
allowing more cases where the copy initialization goes through
user defined conversions.

With this patch we stop using this flag in NRVO contexts, to preserve code
that relies on that assumption.
This causes no known functional changes, we just stop firing some asserts
in a cople of included test cases.

Reviewed By: rsmith

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

show more ...

[NFC] More get/removeAttribute() cleanup

Implemented [[clang::musttail]] attribute for guaranteed tail calls.

This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.

The [[clang::musttail]]

Implemented [[clang::musttail]] attribute for guaranteed tail calls.

This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.

The [[clang::musttail]] attribute goes on a return statement, not
a function definition. There are several constraints that the user
must follow when using [[clang::musttail]], and these constraints
are verified by Sema.

Tail calls are supported on regular function calls, calls through a
function pointer, member function calls, and even pointer to member.

Future work would be to throw a warning if a users tries to pass
a pointer or reference to a local variable through a musttail call.

Reviewed By: rsmith

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

show more ...

[OpaquePtrs] Remove some uses of type-less CreateGEP() (NFC)

This removes some (but not all) uses of type-less CreateGEP()
and CreateInBoundsGEP() APIs, which are incompatible with opaque
pointers.

[OpaquePtrs] Remove some uses of type-less CreateGEP() (NFC)

This removes some (but not all) uses of type-less CreateGEP()
and CreateInBoundsGEP() APIs, which are incompatible with opaque
pointers.

There are a still a number of tricky uses left, as well as many
more variation APIs for CreateGEP.

show more ...

De-templatify EmitCallArgs argument type checking, NFCI

This template exists to abstract over FunctionPrototype and
ObjCMethodDecl, which have similar APIs for storing parameter types. In
place of a

De-templatify EmitCallArgs argument type checking, NFCI

This template exists to abstract over FunctionPrototype and
ObjCMethodDecl, which have similar APIs for storing parameter types. In
place of a template, use a PointerUnion with two cases to handle this.
Hopefully this improves readability, since the type of the prototype is
easier to discover. This allows me to sink this code, which is mostly
assertions, out of the header file and into the cpp file. I can also
simplify the overloaded methods for computing isGenericMethod, and get
rid of the second EmitCallArgs overload.

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

show more ...

[FE] Use preferred alignment instead of ABI alignment for complete object when applicable

On some targets, preferred alignment is larger than ABI alignment in some cases. For example,
on AIX we have

[FE] Use preferred alignment instead of ABI alignment for complete object when applicable

On some targets, preferred alignment is larger than ABI alignment in some cases. For example,
on AIX we have special power alignment rules which would cause that. Previously, to support
those cases, we added a “PreferredAlignment” field in the `RecordLayout` to store the AIX
special alignment values in “PreferredAlignment” as the community suggested.

However, that patch alone is not enough. There are places in the Clang where `PreferredAlignment`
should have been used instead of ABI-specified alignment. This patch is aimed at fixing those
spots.

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

show more ...

[CodeGen][typeid] Emit typeinfo directly if type is known at compile-time

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

[Ignore Expressions][NFC] Refactor to better use `IgnoreExpr.h` and nits

This change groups
* Rename: `ignoreParenBaseCasts` -> `IgnoreParenBaseCasts` for uniformity
* Rename: `IgnoreConversionOpera

[Ignore Expressions][NFC] Refactor to better use `IgnoreExpr.h` and nits

This change groups
* Rename: `ignoreParenBaseCasts` -> `IgnoreParenBaseCasts` for uniformity
* Rename: `IgnoreConversionOperator` -> `IgnoreConversionOperatorSingleStep` for uniformity
* Inline `IgnoreNoopCastsSingleStep` into a lambda inside `IgnoreNoopCasts`
* Refactor `IgnoreUnlessSpelledInSource` to make adequate use of `IgnoreExprNodes`

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

show more ...

PR46908: Emit undef destroying_delete_t as an aggregate RValue.

We previously used a non-aggregate RValue to represent the passed value,
which violated the assumptions of call arg lowering in some c

PR46908: Emit undef destroying_delete_t as an aggregate RValue.

We previously used a non-aggregate RValue to represent the passed value,
which violated the assumptions of call arg lowering in some cases, in
particular on 32-bit Windows, where we'd end up producing an FCA store
with TBAA metadata, that the IR verifier would reject.

show more ...

Change debuginfo check for addHeapAllocSiteMetadata

Summary:
Move check inside of addHeapAllocSiteMetadata().
Change check to DebugInfo <= DebugLineTablesOnly.

Reviewers: akhuang

Subscribers: cfe-

Change debuginfo check for addHeapAllocSiteMetadata

Summary:
Move check inside of addHeapAllocSiteMetadata().
Change check to DebugInfo <= DebugLineTablesOnly.

Reviewers: akhuang

Subscribers: cfe-commits

Tags: #clang

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

show more ...

Reland (again) D80966 [codeview] Put !heapallocsite on calls to operator new

Check that getDebugInfo() is not null, as in the first revision, before
calling getDebugInfo()->addHeapAllocSiteMetadata(

Reland (again) D80966 [codeview] Put !heapallocsite on calls to operator new

Check that getDebugInfo() is not null, as in the first revision, before
calling getDebugInfo()->addHeapAllocSiteMetadata().
Else would cause a crash with a new expression in a default arg.

---

Clang marks calls to operator new as heap allocation sites, but the
operator declared at global scope returns a void pointer. There is no
explicit cast in the code, so the compiler has to write down the
allocated type itself.

Also generalize a cast to use CallBase, so that we mark heap alloc sites
when exceptions are enabled.

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

show more ...

Revert "Reland D80966 [codeview] Put !heapallocsite on calls to operator new"

This reverts commit b6e143aa5448bbe29da7b045072e66a31813bced.

Causes https://bugs.chromium.org/p/chromium/issues/detail

Revert "Reland D80966 [codeview] Put !heapallocsite on calls to operator new"

This reverts commit b6e143aa5448bbe29da7b045072e66a31813bced.

Causes https://bugs.chromium.org/p/chromium/issues/detail?id=1092370#c5.
Will investigate and reland (again).

show more ...

Reland D80966 [codeview] Put !heapallocsite on calls to operator new

With a change to use `CGM.getCodeGenOpts().getDebugInfo() != codegenoptions::NoDebugInfo`
instead of `getDebugInfo()`,
to fix `Pr

Reland D80966 [codeview] Put !heapallocsite on calls to operator new

With a change to use `CGM.getCodeGenOpts().getDebugInfo() != codegenoptions::NoDebugInfo`
instead of `getDebugInfo()`,
to fix `Profile-<arch> :: instrprof-gcov-multithread_fork.test`

See CodeGenModule::CodeGenModule, `EmitGcovArcs || EmitGcovNotes` can
set `clang::CodeGen::CodeGenModule::DebugInfo`.

---

Clang marks calls to operator new as heap allocation sites, but the
operator declared at global scope returns a void pointer. There is no
explicit cast in the code, so the compiler has to write down the
allocated type itself.

Also generalize a cast to use CallBase, so that we mark heap alloc sites
when exceptions are enabled.

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

show more ...

Revert "[codeview] Put !heapallocsite on calls to operator new"

This reverts commit 672ed5386024ba5cee53e19d637b7920a4889837.

This commit is hitting an assertion failure across multiple bots in the

Revert "[codeview] Put !heapallocsite on calls to operator new"

This reverts commit 672ed5386024ba5cee53e19d637b7920a4889837.

This commit is hitting an assertion failure across multiple bots in the test:
Profile-<arch> :: instrprof-gcov-multithread_fork.test

Failing bots include:
http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2205
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/8967
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10789
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/27750
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/16751

show more ...

PR34581: Don't remove an 'if (p)' guarding a call to 'operator delete(p)' under -Oz.

Summary:
This transformation is correct for a builtin call to 'free(p)', but not
for 'operator delete(p)'. There

PR34581: Don't remove an 'if (p)' guarding a call to 'operator delete(p)' under -Oz.

Summary:
This transformation is correct for a builtin call to 'free(p)', but not
for 'operator delete(p)'. There is no guarantee that a user replacement
'operator delete' has no effect when called on a null pointer.

However, the principle behind the transformation *is* correct, and can
be applied more broadly: a 'delete p' expression is permitted to
unconditionally call 'operator delete(p)'. So do that in Clang under
-Oz where possible. We do this whether or not 'p' has trivial
destruction, since the destruction might turn out to be trivial after
inlining, and even for a class-specific (but non-virtual,
non-destroying, non-array) 'operator delete'.

Reviewers: davide, dnsampaio, rjmccall

Reviewed By: dnsampaio

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

[codeview] Put !heapallocsite on calls to operator new

Clang marks calls to operator new as heap allocation sites, but the
operator declared at global scope returns a void pointer. There is no
expli

[codeview] Put !heapallocsite on calls to operator new

Clang marks calls to operator new as heap allocation sites, but the
operator declared at global scope returns a void pointer. There is no
explicit cast in the code, so the compiler has to write down the
allocated type itself.

Also generalize a cast to use CallBase, so that we mark heap alloc sites
when exceptions are enabled.

Reviewed By: MaskRay

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

show more ...