Identified with misc-include-cleaner.
Add `Intrinsic::getDeclarationIfExists` to lookup an existing declaration of an intrinsic in a `Module`.
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds `getDataLayout()` helpers to Function and GlobalValue, replacing the current `getParent()->getDataLayout()` pattern.
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.
This adds a type_checked_load_relative intrinsic whose semantics it is to load a relative function pointer. A relative function pointer is a pointer to a 32bit value that when added to its address yields the address of the function. Differential Revision: https://reviews.llvm.org/D143204
Mostly removing includes of InitializePasses.h and Pass.h in passes that no longer has support for the legacy PM.
Namely CrossDSOCFI and GlobalSplit. These are part of the optimization pipeline, of which the legacy pass manager version is deprecated.
Summary: First patch to support Safe Whole Program Devirtualization Enablement, see RFC here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html Always emit !vcall_visibility metadata under -fwhole-program-vtables, and not just for -fvirtual-function-elimination. The vcall visibility metadata will (in a subsequent patch) be used to communicate to WPD which vtables are safe to devirtualize, and we will optionally convert the metadata to hidden visibility at link time. Subsequent follow on patches will help enable this by adding vcall_visibility metadata to the ThinLTO summaries, and always emit type test intrinsics under -fwhole-program-vtables (and not just for vtables with hidden visibility). In order to do this safely with VFE, since for VFE all vtable loads must be type checked loads which will no longer be the case, this patch adds a new "Virtual Function Elim" module flag to communicate to GlobalDCE whether to perform VFE using the vcall_visibility metadata. One additional advantage of using the vcall_visibility metadata to drive more WPD at LTO link time is that we can use the same mechanism to enable more aggressive VFE at LTO link time as well. The link time option proposed in the RFC will convert vcall_visibility metadata to hidden (aka linkage unit visibility), which combined with -fvirtual-function-elimination will allow it to be done more aggressively at LTO link time under the same conditions. Reviewers: pcc, ostannard, evgeny777, steven_wu Subscribers: mehdi_amini, Prazek, hiraditya, dexonsmith, davidxl, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71907