Reapply "[LLVM][LTO] Factor out RTLib calls and allow them to be dropped (#98512)"

This reverts commit 740161a9b98c9920dedf1852b5f1c94d0a683af5.

I moved the `ISD` dependencies into the CodeGen port

Reapply "[LLVM][LTO] Factor out RTLib calls and allow them to be dropped (#98512)"

This reverts commit 740161a9b98c9920dedf1852b5f1c94d0a683af5.

I moved the `ISD` dependencies into the CodeGen portion of the handling,
it's a little awkward but it's the easiest solution I can think of for
now.

show more ...

Revert "[LLVM][LTO] Factor out RTLib calls and allow them to be dropped (#98512)"

This reverts commit c05126bdfc3b02daa37d11056fa43db1a6cdef69.
(llvmorg-19-init-17714-gc05126bdfc3b)
See #99610

[LLVM][LTO] Factor out RTLib calls and allow them to be dropped (#98512)

Summary:
The LTO pass and LLD linker have logic in them that forces extraction
and prevent internalization of needed runtime

[LLVM][LTO] Factor out RTLib calls and allow them to be dropped (#98512)

Summary:
The LTO pass and LLD linker have logic in them that forces extraction
and prevent internalization of needed runtime calls. However, these
currently take all RTLibcalls into account, even if the target does not
support them. The target opts-out of a libcall if it sets its name to
nullptr. This patch pulls this logic out into a class in the header so
that LTO / lld can use it to determine if a symbol actually needs to be
kept.

This is important for targets like AMDGPU that want to be able to use
`lld` to perform the final link step, but does not want the overhead of
uncalled functions. (This adds like a second to the link time trivially)

show more ...

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...

[IRSymtab] Replace linear time lookup with DenseSet (#66376)

There is an inefficiency in the IRSymtab Builder where it does a lookup
of PreservedSymbols when calling addSymbol. This lookup is linea

[IRSymtab] Replace linear time lookup with DenseSet (#66376)

There is an inefficiency in the IRSymtab Builder where it does a lookup
of PreservedSymbols when calling addSymbol. This lookup is linear in
time, so it tends to be quite slow. Replacing it with DenseSet gives a
0.1% speedup:

https://llvm-compile-time-tracker.com/compare.php?from=02d27eac0f3f470a93635fc98ae990bf2a9809ed&to=62b09786fff4d53aa0c75b64aea48de241e4a856&stat=instructions:u

This change is quite similar to https://reviews.llvm.org/D157951.

show more ...

[nfc][llvm] Replace pointer cast functions in PointerUnion by llvm casting functions.

This patch replaces the uses of PointerUnion.is function by llvm::isa,
PointerUnion.get function by llvm::cast,

[nfc][llvm] Replace pointer cast functions in PointerUnion by llvm casting functions.

This patch replaces the uses of PointerUnion.is function by llvm::isa,
PointerUnion.get function by llvm::cast, and PointerUnion.dyn_cast by
llvm::dyn_cast_if_present. This is according to the FIXME in
the definition of the class PointerUnion.

This patch does not remove them as they are being used in other
subprojects.

Reviewed By: mehdi_amini

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

show more ...

Move global namespace cl::opt inside llvm::

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[rereland][Alignment][NFC] Remove access to deprecated GlobalObject::getAlignment from llvm

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

Revert "[reland][Alignment][NFC] Remove access to deprecated GlobalObject::getAlignment from llvm"

This reverts commit 3bbfaee23d41c099547c652f87b252ab6e1f6c46.

[reland][Alignment][NFC] Remove access to deprecated GlobalObject::getAlignment from llvm

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

Revert D139836 "[Alignment][NFC] Remove deprecated GlobalObject::getAlignment"

This breaks lldb.

This reverts commit f3f15ca27fbb433ad5a65b1a1e0a071d2e9af505.

[Alignment][NFC] Remove deprecated GlobalObject::getAlignment

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

Cleanup LLVMObject headers

Most notably,

llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h
llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h
llvm/Object/TapiUn

Cleanup LLVMObject headers

Most notably,

llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h
llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h
llvm/Object/TapiUniversal.h no longer includes llvm/Object/TapiFile.h

llvm-project preprocessed size:
before: 1068185081
after: 1068324320

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119457

show more ...

[LTO] An option to disable automatic bitcode upgrade

Bitcode upgrade automatically takes in place when the current compiler version doesn't match the one building the input modules. The upgrade is v

[LTO] An option to disable automatic bitcode upgrade

Bitcode upgrade automatically takes in place when the current compiler version doesn't match the one building the input modules. The upgrade is very expansive for large applications and unnecessary when users are sure the two compilers do not have a version issue, even if their versions mismatch literally. An optional to disable the automatic bitcode upgrade will be handy in such case.

Reviewed By: wenlei

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

show more ...

[IRSymTab] Mark __stack_chk_guard used

`__stack_chk_guard` is a global variable that has no uses before the LLVM code generation phase (how it is defined is platform-dependent). LTO needs to preserv

[IRSymTab] Mark __stack_chk_guard used

`__stack_chk_guard` is a global variable that has no uses before the LLVM code generation phase (how it is defined is platform-dependent). LTO needs to preserve this symbol for that reason. Currently, legacy LTO API preserves it by hardcoding the logic in Internalizer, but this symbol is not preserved by regular LTO API in thinlink phase. This patch marks `__stack_chk_guard` used during IR symbol table writing since this is how builtin functions are preserved by thinlink by using `RuntimeLibcalls.def`.

Reviewed By: MaskRay, tejohnson

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

show more ...

[IR][NFC] Rename getBaseObject to getAliaseeObject

To better reflect the meaning of the now-disambiguated {GlobalValue,
GlobalAlias}::getBaseObject after breaking off GlobalIFunc::getResolverFunctio

[IR][NFC] Rename getBaseObject to getAliaseeObject

To better reflect the meaning of the now-disambiguated {GlobalValue,
GlobalAlias}::getBaseObject after breaking off GlobalIFunc::getResolverFunction
(D109792), the function is renamed to getAliaseeObject.

show more ...

Resolve {GlobalValue,GloalIndirectSymol}::getBaseObject confusion

While both GlobalAlias and GlobalIFunc are GlobalIndirectSymbol, their
`getIndirectSymbol()` usage is quite different (GlobalIFunc's

Resolve {GlobalValue,GloalIndirectSymol}::getBaseObject confusion

While both GlobalAlias and GlobalIFunc are GlobalIndirectSymbol, their
`getIndirectSymbol()` usage is quite different (GlobalIFunc's resolver
is an entity different from GlobalIFunc itself).

As discussed on https://lists.llvm.org/pipermail/llvm-dev/2020-September/144904.html
("[IR] Modelling of GlobalIFunc"), the name `getBaseObject` is confusing when
used with GlobalIFunc.

To resolve the confusion:

* Move GloalIndirectSymol::getBaseObject to GlobalAlias:: (GlobalIFunc should use `getResolver` instead)
* Change GlobalValue::getBaseObject not to inspect GlobalIFunc. Note: the function has 7 references.
* Add GlobalIFunc::getResolverFunction to peel off potential ConstantExpr indirection
(`strlen` in `test/LTO/Resolution/X86/ifunc.ll`)

Note: GlobalIFunc::getResolver (like GlobalAlias::getAliasee which does not peel
off ConstantExpr indirection) is kept to be used by ValueEnumerator.

Reviewed By: ibookstein

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

show more ...

[LTO] Add SelectionKind to IRSymtab and use it in ld.lld/LLVMgold

In PGO, a C++ external linkage function `foo` has a private counter
`__profc_foo` and a private `__profd_foo` in a `comdat nodedupli

[LTO] Add SelectionKind to IRSymtab and use it in ld.lld/LLVMgold

In PGO, a C++ external linkage function `foo` has a private counter
`__profc_foo` and a private `__profd_foo` in a `comdat nodeduplicate`.

A `__attribute__((weak))` function `foo` has a weak hidden counter `__profc_foo`
and a private `__profd_foo` in a `comdat nodeduplicate`.

In `ld.lld a.o b.o`, say a.o defines an external linkage `foo` and b.o
defines a weak `foo`. Currently we treat `comdat nodeduplicate` as `comdat any`,
ld.lld will incorrectly consider `b.o:__profc_foo` non-prevailing. In the worst
case when `b.o:__profd_foo` is retained and `b.o:__profc_foo` isn't, there will
be dangling reference causing an `undefined hidden symbol` error.

Add SelectionKind to `Comdat` in IRSymtab and let linkers ignore nodeduplicate comdat.

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

show more ...

[NFC][OpaquePtr] Use GlobalValue::getValueType() more

Instead of getType()->getElementType().

PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23

C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible wit

PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23

C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible with C++23 (& a follow-up change I've made
will make this ambiguous/invalid even in <C++23 so we don't regress
this & it generally improves the code anyway)

show more ...

[IRSymTab] Set FB_used on llvm.compiler.used symbols

IR symbol table does not parse inline asm. A symbol only referenced by inline
asm is not in the IR symbol table, so LTO does not know that the de

[IRSymTab] Set FB_used on llvm.compiler.used symbols

IR symbol table does not parse inline asm. A symbol only referenced by inline
asm is not in the IR symbol table, so LTO does not know that the definition (in
another translation unit) is referenced and may internalize it, even if that
definition has `__attribute__((used))` (which lowers to `llvm.compiler.used` on
ELF targets since D97446).

```
// cabac.c
__attribute__((used)) const uint8_t ff_h264_cabac_tables[...] = {...};

// h264_cabac.c
asm("lea ff_h264_cabac_tables(%rip), %0" : ...);
```

`__attribute__((used))` is the recommended way to tell the compiler there may
be inline asm references, so the usage is perfectly fine. This patch
conservatively sets the `FB_used` bit on `llvm.compiler.used` symbols to work
around the IR symbol table limitation. Note: before D97446, Clang never emitted
symbols in the `llvm.compiler.used` list, so this change does not punish any
Clang emitted global object.

Without the patch, `ff_h264_cabac_tables` may be assigned to a non-external
partition and get internalized. Then we will get a linker error because the
`cabac.c` definition is not exposed.

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

show more ...

collectUsedGlobalVariables: migrate SmallPtrSetImpl overload to SmallVecImpl overload after D97128

And delete the SmallPtrSetImpl overload.

While here, decrease inline element counts from 8 to 4. S

collectUsedGlobalVariables: migrate SmallPtrSetImpl overload to SmallVecImpl overload after D97128

And delete the SmallPtrSetImpl overload.

While here, decrease inline element counts from 8 to 4. See D97128 for the choice.

Reviewed By: tejohnson

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

show more ...

[llvm] Use llvm::is_contained (NFC)

Remove GlobalValue::getAlignment().

This function is deceptive at best: it doesn't return what you'd expect.
If you have an arbitrary GlobalValue and you want to determine the
alignment of that poin

Remove GlobalValue::getAlignment().

This function is deceptive at best: it doesn't return what you'd expect.
If you have an arbitrary GlobalValue and you want to determine the
alignment of that pointer, Value::getPointerAlignment() returns the
correct value. If you want the actual declared alignment of a function
or variable, GlobalObject::getAlignment() returns that.

This patch switches all the users of GlobalValue::getAlignment to an
appropriate alternative.

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

show more ...