[IR] Allow absence for Min module flags and make AArch64 BTI/PAC-RET flags backward compatible

D123493 introduced llvm::Module::Min to encode module flags metadata for AArch64
BTI/PAC-RET. llvm::Mod

[IR] Allow absence for Min module flags and make AArch64 BTI/PAC-RET flags backward compatible

D123493 introduced llvm::Module::Min to encode module flags metadata for AArch64
BTI/PAC-RET. llvm::Module::Min does not take effect when the flag is absent in
one module. This behavior is misleading and does not address backward
compatibility problems (when a bitcode with "branch-target-enforcement"==1 and
another without the flag are merged, the merge result is 1 instead of 0).

To address the problems, require Min flags to be non-negative and treat absence
as having a value of zero. For an old bitcode without
"branch-target-enforcement"/"sign-return-address", its value is as if 0.

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

show more ...

[NFC][Metadata] Change MDNode::operands()'s return type from op_range to ArrayRef<MDOperand>

This patch is https://reviews.llvm.org/D129468 follow-up and address one of comment
coming from that revi

[NFC][Metadata] Change MDNode::operands()'s return type from op_range to ArrayRef<MDOperand>

This patch is https://reviews.llvm.org/D129468 follow-up and address one of comment
coming from that review: https://reviews.llvm.org/D129468#3643295

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

show more ...

[Metadata] Utilize the resizing capability of MDNodes in Moduleflag processing.

This mostly affects PGO/LTO builds which use module flags describing the call
graph. Fixes Issue #51893.

Reviewed By:

[Metadata] Utilize the resizing capability of MDNodes in Moduleflag processing.

This mostly affects PGO/LTO builds which use module flags describing the call
graph. Fixes Issue #51893.

Reviewed By: dexonsmith

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

show more ...

[llvm] Don't use Optional::getValue (NFC)

Support the min of module flags when linking, use for AArch64 BTI/PAC-RET

LTO objects might compiled with different `mbranch-protection` flags which will cause an error in the linker.
Such a setup i

Support the min of module flags when linking, use for AArch64 BTI/PAC-RET

LTO objects might compiled with different `mbranch-protection` flags which will cause an error in the linker.
Such a setup is allowed in the normal build with this change that is possible.

Reviewed By: pcc

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

show more ...

[PseudoProbe] Do not emit pseudo probes when module is not probed.

There is a case when a function has pseudo probe intrinsics but the module it resides does not have the probe desc. This could happ

[PseudoProbe] Do not emit pseudo probes when module is not probed.

There is a case when a function has pseudo probe intrinsics but the module it resides does not have the probe desc. This could happen when the current module is not built with `-fpseudo-probe-for-profiling` while a function in it calls some other function from a probed module. In thinLTO mode, the callee function could be imported and inlined into the current function.
While this is undefined behavior, I'm fixing the asm printer to not ICE and warn user about this.

Reviewed By: wenlei

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

show more ...

Cleanup includes: Linker

Preprocessor output diff: -7300 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D12

Cleanup includes: Linker

Preprocessor output diff: -7300 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D122182

show more ...

[IRLinker] make IRLinker::AddLazyFor optional (llvm::unique_function). NFC

2 of the 3 callsite of IRMover::move() pass empty lambda functions. Just
make this parameter llvm::unique_function.

Came a

[IRLinker] make IRLinker::AddLazyFor optional (llvm::unique_function). NFC

2 of the 3 callsite of IRMover::move() pass empty lambda functions. Just
make this parameter llvm::unique_function.

Came about via discussion in D120781. Probably worth making this change
regardless of the resolution of D120781.

Reviewed By: dexonsmith

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

show more ...

[NFC] Replace some deprecated getAlignment() calls with getAlign()

Reviewed By: gchatelet

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

[IR] Refactor GlobalIFunc to inherit from GlobalObject, Remove GlobalIndirectSymbol

As discussed in:
* https://reviews.llvm.org/D94166
* https://lists.llvm.org/pipermail/llvm-dev/2020-September/1450

[IR] Refactor GlobalIFunc to inherit from GlobalObject, Remove GlobalIndirectSymbol

As discussed in:
* https://reviews.llvm.org/D94166
* https://lists.llvm.org/pipermail/llvm-dev/2020-September/145031.html

The GlobalIndirectSymbol class lost most of its meaning in
https://reviews.llvm.org/D109792, which disambiguated getBaseObject
(now getAliaseeObject) between GlobalIFunc and everything else.
In addition, as long as GlobalIFunc is not a GlobalObject and
getAliaseeObject returns GlobalObjects, a GlobalAlias whose aliasee
is a GlobalIFunc cannot currently be modeled properly. Creating
aliases for GlobalIFuncs does happen in the wild (e.g. glibc). In addition,
calling getAliaseeObject on a GlobalIFunc will currently return nullptr,
which is undesirable because it should return the object itself for
non-aliases.

This patch refactors the GlobalIFunc class to inherit directly from
GlobalObject, and removes GlobalIndirectSymbol (while inlining the
relevant parts into GlobalAlias and GlobalIFunc). This allows for
calling getAliaseeObject() on a GlobalIFunc to return the GlobalIFunc
itself, making getAliaseeObject() more consistent and enabling
alias-to-ifunc to be properly modeled in the IR.

I exercised some judgement in the API clients of GlobalIndirectSymbol:
some were 'monomorphized' for GlobalAlias and GlobalIFunc, and
some remained shared (with the type adapted to become GlobalValue).

Reviewed By: MaskRay

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

show more ...

Copy Elementtype Attribute to IR at Link step

Copying IR during linking causes a type mismatch due to the field being missing in IRMover/Valuemapper. Adds the full range of typed attributes includin

Copy Elementtype Attribute to IR at Link step

Copying IR during linking causes a type mismatch due to the field being missing in IRMover/Valuemapper. Adds the full range of typed attributes including elementtype attribute in the copy functions.

Patch by Chenyang Liu

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

show more ...

[NFC] Use newly introduced *AtIndex methods

Introduced in D108788. These are clearer.

[IRLinker] Suppress linker warnings when linking with CUDA libdevice.

libdevice bitcode provided by NVIDIA is linked with clang/LLVM-generated IR
which uses nvptx*-nvidia-cuda triple. We need to mar

[IRLinker] Suppress linker warnings when linking with CUDA libdevice.

libdevice bitcode provided by NVIDIA is linked with clang/LLVM-generated IR
which uses nvptx*-nvidia-cuda triple. We need to mark them as compatible.

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

show more ...

[CSSPGO] Do not import pseudo probe desc in thinLTO

Previously we reliedy on pseudo probe descriptors to look up precomputed GUID during probe emission for inlined probes. Since we are moving to alw

[CSSPGO] Do not import pseudo probe desc in thinLTO

Previously we reliedy on pseudo probe descriptors to look up precomputed GUID during probe emission for inlined probes. Since we are moving to always using unique linkage names, GUID for functions can be computed in place from dwarf names. This eliminates the need of importing pseudo probe descs in thinlto, since those descs should be emitted by the original modules.

This significantly reduces thinlto memory footprint in some extreme case where the number of imported modules for a single module is massive.

Test Plan:

Reviewed By: wenlei

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

show more ...

Linker: Avoid scheduling the link of a global value twice due to an alias

3d4f3a0da90bd1a3 (https://reviews.llvm.org/D20586) avoided rescheduling
a global value that was materialized first through a

Linker: Avoid scheduling the link of a global value twice due to an alias

3d4f3a0da90bd1a3 (https://reviews.llvm.org/D20586) avoided rescheduling
a global value that was materialized first through a regular value, and
then again through an alias. This commit catches the dual, avoiding
rescheduling when the global value is first materialized through an
alias.

Differential Revision: https://reviews.llvm.org/D101419
Radar-Id: rdar://75752728

show more ...

Preserve the lexical order for global variables during llvm-link merge

The order of global variables is generated in the order of recursively materializing variables if the global variable has the a

Preserve the lexical order for global variables during llvm-link merge

The order of global variables is generated in the order of recursively materializing variables if the global variable has the attribute of hasLocalLinkage or hasLinkOnceLinkage during the module merging. In practice, it is often the exact reverse of source order. This new order may cause performance regression.

The change is to preserve the original lexical order for global variables.

Reviewed By: jdoerfert, dexonsmith

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

show more ...

Reapply "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.

Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""

Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a2

Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""

Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a23d7a.

show more ...

Reapply "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 20d5c42e0ef5d252b434bcb610b04f1cb79fe771.

Revert "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 4fefed65637ec46c8c2edad6b07b5569ac61e9e5.
Broke check-clang everywhere.

OpaquePtr: Turn inalloca into a type attribute

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inall

OpaquePtr: Turn inalloca into a type attribute

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inalloca, so catch this up to the others so that can
happen.

show more ...

Support intrinsic overloading on unnamed types

This patch adds support for intrinsic overloading on unnamed types.

This fixes PR38117 and PR48340 and will also be needed for the Full Restrict Patch

Support intrinsic overloading on unnamed types

This patch adds support for intrinsic overloading on unnamed types.

This fixes PR38117 and PR48340 and will also be needed for the Full Restrict Patches (D68484).

The main problem is that the intrinsic overloading name mangling is using 's_s' for unnamed types.
This can result in identical intrinsic mangled names for different function prototypes.

This patch changes this by adding a '.XXXXX' to the intrinsic mangled name when at least one of the types is based on an unnamed type, ensuring that we get a unique name.

Implementation details:
- The mapping is created on demand and kept in Module.
- It also checks for existing clashes and recycles potentially existing prototypes and declarations.
- Because of extra data in Module, Intrinsic::getName needs an extra Module* argument and, for speed, an optional FunctionType* argument.
- I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (providing the base name).
-- Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is
-- The current situation already has a limitation. So that should not get worse with this patch.
- Intrinsic::getDeclaration and the verifier are now using the new version.

Other notes:
- As far as I see, this should not suffer from stability issues. The count is only added for prototypes depending on at least one anonymous struct
- The initial count starts from 0 for each intrinsic mangled name.
- In case of name clashes, existing prototypes are remembered and reused when that makes sense.

Reviewed By: fhahn

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

show more ...

[llvm-link] fix IRMover returning wrong modified vector type

Modified scalable vector types weren't correctly returned at link-time.
The previous behaviour was a FixedVectorType was constructed
when

[llvm-link] fix IRMover returning wrong modified vector type

Modified scalable vector types weren't correctly returned at link-time.
The previous behaviour was a FixedVectorType was constructed
when expecting a ScalableVectorType. This commit has added a regression
test which re-creates the failure as well as a fix.

Reviewed By: sdesmalen

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

show more ...

ValueMapper: Rename RF_MoveDistinctMDs => RF_ReuseAndMutateDistinctMDs, NFC

Rename the `RF_MoveDistinctMDs` flag passed into `MapValue` and
`MapMetadata` to `RF_ReuseAndMutateDistinctMDs` in order t

ValueMapper: Rename RF_MoveDistinctMDs => RF_ReuseAndMutateDistinctMDs, NFC

Rename the `RF_MoveDistinctMDs` flag passed into `MapValue` and
`MapMetadata` to `RF_ReuseAndMutateDistinctMDs` in order to more
precisely describe its effect and clarify the header documentation.

Found this while helping to investigate PR48841, which pointed out an
unsound use of the flag in `CloneModule()`. For now I've just added a
FIXME there, but I'm hopeful that the new (more precise) name will
prevent other similar errors.

show more ...

[llvm-link] Fix for an assertion when linking global with appending linkage

This patch fixes llvm-link assertion when linking external variable
declaration with a definition with appending linkage.

[llvm-link] Fix for an assertion when linking global with appending linkage

This patch fixes llvm-link assertion when linking external variable
declaration with a definition with appending linkage.

Reviewed By: jdoerfert

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

show more ...