When a customer class inherits from a libc++ class, and is built with "-flto -fwhole-program-vtables -static-libstdc++ \ -Wl,-plugin-opt=-whole-program-visibility", the libc++ class's vtable is available_externally, meanwhile the customer class vtable is private. And both of them are !vcall_visibility == Linkage Unit. In this case, icall.branch.funnel might be generated. But the icall.branch.funnel would cause crash in LowerTypeTests because available_externally Global_Object's GlobalTypeMember would not be saved and finally leads to a NULL GlobalTypeMember which causes a crash. Even saving the available_externally GO's GlobalTypeMember so that it is not NULL to avoid the crash in LowerTypeTests, it still will crash in SelectionDAGBuilder or Verifier, because operands linkage type consistency check of icall.branch.funnel can not pass. So any one of available externally vtable would stop to generate icall.branch.funnel. This patch fixes FullLTO mode and split-LTO-unit ThinLTO mode.
We'd hit an assertion checking proper alignment for an i8 when building chromium because we used the prefered alignment (which is 4 bytes) instead of the ABI alignment (which is 1 byte). The ABI alignment should be used because that's the actual alignment needed to load a constant from the vtable. This also updates the two `virtual-const-prop-small-alignment-*` to explicitly give ABI alignments for i64s.
It's possible for virtual constant propagation in whole program devirtualization to create unaligned loads. We originally saw this with 4-byte aligned relative vtables where we could store 8-byte values before/after the vtable. But since the vtable is 4-byte aligned and we unconditionally do an 8-byte load, we can't guarantee that the stored constant will always be aligned to 8 bytes. We can also see this with normal vtables whenever a 1-byte char is stored in the vtable because the offset calculation for the GEP doesn't take into account the original vtable alignment. This patch introduces two changes to virtual constant propagation: 1. Do not propagate constants whose preferred alignment is larger than the vtable alignment. This is required because if the constants are stored in the vtable, we can only guarantee the constant will be stored at an address at most aligned to the vtable's alignment. 2. Round up the offset used in the GEP before the load to ensure it's at an address suitably aligned such that we can load from it. This patch updates tests to reflect this alignment change and adds some cases for relative vtables.
This is a patch with precommitted tests to make https://github.com/llvm/llvm-project/pull/136630 easier to review. The `virtual-const-prop-small-alignment-*` tests check the output when the loaded int alignment is less than the vtable alignment. This also changes some constants to make it easier to differentiate between propagated values in vtables.
…elative The semantics of `llvm.type.checked.load.relative` seem to be a little different from that of `llvm.load.relative`. It looks like the semantics for `llvm.type.checked.load.relative` is `ptr + offset + *(ptr + offset)` whereas the semantics for `llvm.load.relative` is `ptr + *(ptr + offset)`. That is, the offset for the former is added to the offset address whereas the later has the offset added to the original pointer. It really feels like the checked intrinsic was meant to match the semantics of the non-checked intrinsic, but I think for all cases the checked intrinsic is used (swift being the only use I know of), the calculation just happens to be the same because swift always uses an offset of zero. Likewise, all llvm tests for this intrinsic happen to use an offset of zero. Relative vtables in clang happens to be the first time where we're using this intrinsic and using it with non-zero values. This updates the semantics of the checked intrinsic to match the non-checked one. Effectively this shouldn't change any codegen by any users of this since all current users seem to use a zero offset. This PR also updates some tests with non-zero offsets.
https://reviews.llvm.org/D115492 skips unreachable functions and potentially allows more static de-virtualizations. The motivation is to ignore virtual deleting destructor of abstract class (e.g., `Base::~Base()` in https://gcc.godbolt.org/z/dWMsdT9Kz). * Note WPD already handles most pure virtual functions (like `Base::x()` in the godbolt example above), which becomes a `__cxa_pure_virtual` in the vtable slot. This PR proposes to undo the change, because it turns out there are other unreachable functions that a general program wants to run and fail intentionally, with `LOG(FATAL)` or `CHECK` [1] for example. While many real-world applications are encouraged to check-fail sparingly, they are allowed to do so on critical errors (e.g., misconfiguration or bug is detected during server startup). * Implementation-wise, this PR keeps the one-bit 'unreachable' state in bitcode and updates WPD analysis. https://gcc.godbolt.org/z/T1aMhczYr is a minimum reproducible example extracted from unit test. `Base::func` is a one-liner of `LOG(FATAL) << "message"`, and lowered to one basic block ending with `unreachable`. A real-world program is _allowed_ to invoke Base::func to terminate the program as a way to report errors (in server initialization stage for example), even if errors on the serving path should be handled more gracefully. [1] https://abseil.io/docs/cpp/guides/logging#CHECK and https://abseil.io/docs/cpp/guides/logging#configuration-and-flags
This option applies for _import_ WPD (i.e., when `DevirtModule` pass de-virtualizes according to an imported summary, in ThinLTO backend pipeline). It's meant for debugging (e.g., bisection).
Also reapply "[llvm] Teach whole program devirtualization about relative vtables" This reverts commit 1c604a9780fcfe92a99d539913553f0835b81de3 and 474f5efebed24547e76d022f0c5ffcc9db97ce6f.
This reverts commit 09c3bfe9b3eb47a2af0c10531b25f90cfb5fa9f4.
This reverts commit 474f5efebed24547e76d022f0c5ffcc9db97ce6f.