[Clang][CodeGen] Fix `CanSkipVTablePointerInitialization` for dynamic classes with a trivial anonymous union (#84651)

Hit this when trying upgrade an old project of mine. I couldn't find a
correspo

[Clang][CodeGen] Fix `CanSkipVTablePointerInitialization` for dynamic classes with a trivial anonymous union (#84651)

Hit this when trying upgrade an old project of mine. I couldn't find a
corresponding existing issue for this when spelunking the open issues
here on github.
Thankfully I can work-around it today with the `[[clang::no_destroy]]`
attribute for my use case. However it should still be properly fixed.

### Issue and History ###

https://godbolt.org/z/EYnhce8MK for reference.
All subsequent text below refers to the example in the godbolt above.

Anonymous unions never have their destructor invoked automatically.
Therefore we can skip vtable initialization of the destructor of a
dynamic class if that destructor effectively does no work.

This worked previously as the following check would be hit and return
true for the trivial anonymous union,
https://github.com/llvm/llvm-project/blob/release/18.x/clang/lib/CodeGen/CGClass.cpp#L1348,
resulting in the code skipping vtable initialization.

This was broken here
https://github.com/llvm/llvm-project/commit/982bbf404eba2d968afda5c674d4821652159c53
in relation to comments made on this review here
https://reviews.llvm.org/D10508.

### Fixes ###

The check the code is doing is correct however the return value is
inverted. We want to return true here since a field with anonymous union
never has its destructor invoked and thus effectively has a trivial
destructor body from the perspective of requiring vtable init in the
parent dynamic class.

Also added some extra missing unit tests to test for this use case and a
couple others.

show more ...

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the representation of the `inrange` attribute, which
is used for vtable splitting.

Currently, inrange is specified as follows:

```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2)
```

The `inrange` is placed on a GEP index, and all accesses must be "in
range" of that index. The new representation is as follows:

```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2)
```

This specifies which offsets are "in range" of the GEP result. The new
representation will continue working when canonicalizing to ptradd
representation:

```
getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48)
```

The inrange offsets are relative to the return value of the GEP. An
alternative design could make them relative to the source pointer
instead. The result-relative format was chosen on the off-chance that we
want to extend support to non-constant GEPs in the future, in which case
this variant is more expressive.

This implementation "upgrades" the old inrange representation in bitcode
by simply dropping it. This is a very niche feature, and I don't think
trying to upgrade it is worthwhile. Let me know if you disagree.

show more ...

[CodeGenCXX] Convert some tests to opaque pointers (NFC)

Conversion done using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

These are tests where the conversion wor

[CodeGenCXX] Convert some tests to opaque pointers (NFC)

Conversion done using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

These are tests where the conversion worked out of the box and no
manual fixup was performed.

show more ...

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

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

show more ...

[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences

For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie
and COFF, but not for Mach-O.

[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences

For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie
and COFF, but not for Mach-O. This nuance causes unneeded binary format differences.

This patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `
if there is an explicit linkage.

* Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar.
* Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.

show more ...

CodeGen: Start using inrange annotations on vtable getelementptr.

This annotation allows the optimizer to split vtable groups, as permitted by
a change to the Itanium ABI [1] that prevents compilers

CodeGen: Start using inrange annotations on vtable getelementptr.

This annotation allows the optimizer to split vtable groups, as permitted by
a change to the Itanium ABI [1] that prevents compilers from adjusting virtual
table pointers between virtual tables.

[1] https://github.com/MentorEmbedded/cxx-abi/pull/7

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

llvm-svn: 289585

show more ...

CodeGen: New vtable group representation: struct of vtable arrays.

In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to

CodeGen: New vtable group representation: struct of vtable arrays.

In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to split vtable groups.

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

llvm-svn: 289584

show more ...

CodeGen: Use 32-bit gep offsets to address vtable address points.

The relative vtable ABI will use a struct rather than an array as the type
of a vtable. LLVM only allows 32-bit integers as struct i

CodeGen: Use 32-bit gep offsets to address vtable address points.

The relative vtable ABI will use a struct rather than an array as the type
of a vtable. LLVM only allows 32-bit integers as struct indices, so we need
to use 32-bit integers to get addresses of address points. In order to keep
the code simple, we might as well do that unconditionally.

It's probably a reasonable implementation limit to support no more than 2
billion virtual functions per class.

This change causes quite a bit of churn in the test suite, so I'm making
it separately.

Differential Revision: http://reviews.llvm.org/D18113

llvm-svn: 263469

show more ...

Test case updates for explicit type parameter to the gep operator

llvm-svn: 232187

Cast vtable address points to i32 (...)** to enable more globalopt

We currently use i32 (...)** as the type of the vptr field in the LLVM
struct type. LLVM's GlobalOpt prefers any bitcasts to be on

Cast vtable address points to i32 (...)** to enable more globalopt

We currently use i32 (...)** as the type of the vptr field in the LLVM
struct type. LLVM's GlobalOpt prefers any bitcasts to be on the side of
the data being stored rather than on the pointer being stored to.

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D5916

llvm-svn: 223267

show more ...

CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.

llvm-svn: 188447

Fix another regression from the "skip vtable pointer initialization"
optimization. Make sure to require a vtable when trying to get the address
of a VTT, otherwise we would never end up emitting the

Fix another regression from the "skip vtable pointer initialization"
optimization. Make sure to require a vtable when trying to get the address
of a VTT, otherwise we would never end up emitting the VTT.

llvm-svn: 131400

show more ...

Re-enable the fix for PR9181 now that all the edge cases are handled.

llvm-svn: 131385

Disable the optimization until the bug noticed by Sean Hunt has been fixed.

llvm-svn: 131372

When emitting the destructor for a class with a vtable, if we can determine
that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructo

When emitting the destructor for a class with a vtable, if we can determine
that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructor bodies, we don't need to initialize the
vtable pointers since no virtual member functions will be called on the destructor.

Fixes PR9181.

llvm-svn: 131368

show more ...