[WPD] Use new llvm.public.type.test intrinsic for potentially publicly visible classes

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.t

[WPD] Use new llvm.public.type.test intrinsic for potentially publicly visible classes

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.test)` in WPD so that a later LTT doesn't resolve the type test to undef and introduce an `assume(false)`. The pattern matching can fail in cases where we transform two `assume(type.test)`s into `assume(phi(type.test.1, type.test.2))`.

Currently we create `assume(type.test)` for all virtual calls that might be devirtualized. This is to support `-Wl,--lto-whole-program-visibility`.

To prevent this, all virtual calls that may not be in the same LTO module instead use a new `llvm.public.type.test` intrinsic in place of the `llvm.type.test`. Then when we know if `-Wl,--lto-whole-program-visibility` is passed or not, we can either replace all `llvm.public.type.test` with `llvm.type.test`, or replace all `llvm.public.type.test` with `true`. This prevents WPD from trying to pattern match away `assume(type.test)` for public virtual calls when failing the pattern matching will result in miscompiles.

Reviewed By: tejohnson

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

show more ...

[clang] Use value instead of getValue (NFC)

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[clang] Don't emit type test/assume for virtual classes that should never participate in WPD

Reviewed By: pcc

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

Stricter use-after-dtor detection for trivial members.

Poison trivial class members one-by-one in the reverse order of their
construction, instead of all-at-once at the very end.

For example, in th

Stricter use-after-dtor detection for trivial members.

Poison trivial class members one-by-one in the reverse order of their
construction, instead of all-at-once at the very end.

For example, in the following code access to `x` from `~B` will
produce an undefined value.

struct A {
struct B b;
int x;
};

Reviewed By: kda

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

show more ...

Use-after-dtor detection for trivial base classes.

-fsanitize-memory-use-after-dtor detects memory access after a
subobject is destroyed but its memory is not yet deallocated.
This is done by poison

Use-after-dtor detection for trivial base classes.

-fsanitize-memory-use-after-dtor detects memory access after a
subobject is destroyed but its memory is not yet deallocated.
This is done by poisoning each object memory near the end of its destructor.

Subobjects (members and base classes) do this in their respective
destructors, and the parent class does the same for its members with
trivial destructors.

Inexplicably, base classes with trivial destructors are not handled at
all. This change fixes this oversight by adding the base class poisoning logic
to the parent class destructor.

Reviewed By: vitalybuka

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

show more ...

[clang] Remove Address::deprecated() from CGClass.cpp

[clang] Remove getPointerElementType() in EmitVTableTypeCheckedLoad()

[clang] Remove an Address::deprecated() call in CGClass.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-format one function.

fix code formatting

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

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

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecatin

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecating the API.

show more ...

[CodeGen] Avoid more pointer element type accesses

[CodeGen] Avoid more pointer element type accesses

[CodeGen] Avoid some pointer element type accesses

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

Don't update the vptr at the start of the destructor of a final class.

In this case, we know statically that we're destroying the most-derived
class, so the vptr must already point to the current cl

Don't update the vptr at the start of the destructor of a final class.

In this case, we know statically that we're destroying the most-derived
class, so the vptr must already point to the current class and never
needs to be updated.

show more ...

Fix vtbl field addr space

Storing the vtable field of an object should use the same address space as
the this pointer. Currently it is assumed to be addr space 0 but this may not
be true.

This assu

Fix vtbl field addr space

Storing the vtable field of an object should use the same address space as
the this pointer. Currently it is assumed to be addr space 0 but this may not
be true.

This assumption (added in 054cc3b1b469de4b0cb25d1dc3af43c679c5dc44) caused
issues for the out-of-tree CHERI targets.

Reviewed by: John McCall, Alexander Richardson

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

show more ...

[OpaquePtr] Remove uses of CreateGEP() without element type

Remove uses of to-be-deprecated API. In cases where the correct
element type was not immediately obvious to me, fall back to
explicit getP

[OpaquePtr] Remove uses of CreateGEP() without element type

Remove uses of to-be-deprecated API. In cases where the correct
element type was not immediately obvious to me, fall back to
explicit getPointerElementType().

show more ...

[OpaquePtr] Remove uses of CGF.Builder.CreateConstInBoundsGEP1_64() without type

Remove uses of to-be-deprecated API.

[OpaquePtr] Remove uses of CreateConstInBoundsGEP2_64() without type

Remove uses of to-be-deprecated API.

[CUDA][HIP] Fix store of vtbl in ctor

vtbl itself is in default global address space. When clang emits
ctor, it gets a pointer to the vtbl field based on the this pointer,
then stores vtbl to the po

[CUDA][HIP] Fix store of vtbl in ctor

vtbl itself is in default global address space. When clang emits
ctor, it gets a pointer to the vtbl field based on the this pointer,
then stores vtbl to the pointer.

Since this pointer can point to any address space (e.g. an object
created in stack), this pointer points to default address space, therefore
the pointer to vtbl field in this object should also be in default
address space.

Currently, clang incorrectly casts the pointer to vtbl field in this object
to global address space. This caused assertions in backend.

This patch fixes that by removing the incorrect addr space cast.

Reviewed by: Artem Belevich

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

show more ...

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 ...