[Bitcode] materialize Functions early when BlockAddress taken

IRLinker builds a work list of functions to materialize, then moves them
from a source module to a destination module one at a time.

Th

[Bitcode] materialize Functions early when BlockAddress taken

IRLinker builds a work list of functions to materialize, then moves them
from a source module to a destination module one at a time.

This is a problem for blockaddress Constants, since they need not refer
to the function they are used in; IPSCCP is quite good at sinking these
constants deep into other functions when passed as arguments.

This would lead to curious errors during LTO:
ld.lld: error: Never resolved function from blockaddress ...
based on the ordering of function definitions in IR.

The problem was that IRLinker would basically do:

for function f in worklist:
materialize f
splice f from source module to destination module

in one pass, with Functions being lazily added to the running worklist.
This confuses BitcodeReader, which cannot disambiguate whether a
blockaddress is referring to a function which has not yet been parsed
("materialized") or is simply empty because its body was spliced out.
This causes BitcodeReader to insert Functions into its BasicBlockFwdRefs
list incorrectly, as it will never re-materialize an already
materialized (but spliced out) function.

Because of the possibility that blockaddress Constants may appear in
Functions other than the ones they reference, this patch adds a new
bitcode function code FUNC_CODE_BLOCKADDR_USERS that is a simple list of
Functions that contain BlockAddress Constants that refer back to this
Function, rather then the Function they are scoped in. We then
materialize those functions when materializing `f` from the example loop
above. This might over-materialize Functions should the user of
BitcodeReader ultimately decide not to link those Functions, but we can
at least now we can avoid this ordering related issue with blockaddresses.

Fixes: https://github.com/llvm/llvm-project/issues/52787
Fixes: https://github.com/ClangBuiltLinux/linux/issues/1215

Reviewed By: dexonsmith

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

show more ...

[LLVMContext] Replace enableOpaquePointers() with setOpaquePointers()

This allows both explicitly enabling and explicitly disabling
opaque pointers, in anticipation of the default switching at some

[LLVMContext] Replace enableOpaquePointers() with setOpaquePointers()

This allows both explicitly enabling and explicitly disabling
opaque pointers, in anticipation of the default switching at some
point.

This also slightly changes the rules by allowing calls if either
the opaque pointer mode has not yet been set (explicitly or
implicitly) or if the value remains unchanged.

show more ...

Revert "Revert "[OpaquePointers][BitcodeReader] Enable -opaque-pointers if we see an opaque pointer type""

This reverts commit 80ec0ebfdc5692a58e0832125f2c6a991df9d63f.

Issues were already fixed at

Revert "Revert "[OpaquePointers][BitcodeReader] Enable -opaque-pointers if we see an opaque pointer type""

This reverts commit 80ec0ebfdc5692a58e0832125f2c6a991df9d63f.

Issues were already fixed at head.

show more ...

Revert "[OpaquePointers][BitcodeReader] Enable -opaque-pointers if we see an opaque pointer type"

This reverts commit 46216aa97729aa994dce79e75cd25707fb4b7874.

Dependency https://reviews.llvm.org/D

Revert "[OpaquePointers][BitcodeReader] Enable -opaque-pointers if we see an opaque pointer type"

This reverts commit 46216aa97729aa994dce79e75cd25707fb4b7874.

Dependency https://reviews.llvm.org/D119482 broke the ASan buildbot.

show more ...

[OpaquePointers][BitcodeReader] Enable -opaque-pointers if we see an opaque pointer type

This allows us to more easily test opaque pointers e.g. in the case of
ThinLTO where we only have to pass -op

[OpaquePointers][BitcodeReader] Enable -opaque-pointers if we see an opaque pointer type

This allows us to more easily test opaque pointers e.g. in the case of
ThinLTO where we only have to pass -opaque-pointers to the frontend.

Reviewed By: #opaque-pointers, nikic

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

show more ...

[OpaquePtr][ARM] Use elementtype on ldrex/ldaex/stlex/strex

Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.

[OpaquePtr][ARM] Use elementtype on ldrex/ldaex/stlex/strex

Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.

Basically the same as D120527.

Reviewed By: #opaque-pointers, nikic

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

show more ...

[OpaquePtr][AArch64] Use elementtype on ldxr/stxr

Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.

Reviewed

[OpaquePtr][AArch64] Use elementtype on ldxr/stxr

Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.

Reviewed By: #opaque-pointers, nikic

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

show more ...

[Bitcode] Don't confuse type attributes on declaration and call

We should not be using APIs here that try to fetch the attribute
from both the call attributes and the function attributes. Otherwise

[Bitcode] Don't confuse type attributes on declaration and call

We should not be using APIs here that try to fetch the attribute
from both the call attributes and the function attributes. Otherwise
we'll try to upgrade a non-existent sret attribute on the call using
the attribute on the function.

show more ...

[Bitcode] Encode alloca address space

Since D101045, allocas are no longer required to be part of the
default alloca address space. There may be allocas in multiple
different address spaces. However

[Bitcode] Encode alloca address space

Since D101045, allocas are no longer required to be part of the
default alloca address space. There may be allocas in multiple
different address spaces. However, the bitcode reader would
simply assume the default alloca address space, resulting in
either an error or incorrect IR.

Add an optional record for allocas which encodes the address
space.

show more ...

[Bitcode] Check for type mismatch when assigning value

If the value is forward-declared, then the type must match,
otherwise we can't RAUW.

[Bitcode] Delete phi node on error

These error conditions are checked after the phi node has been
created, so we also need to delete it.

[Bitcode] Improve some error messages

It's not particularly helpful if 95% of our errors just say
"Invalid record". This at least adds the record type to a subset
of errors.

[Bitcode] Delete instruction on error

As these errors are detected after the instruction has already been
created (but before it has been inserted into the function), we
also need to delete it.

[Bitcode] Report error for missing element type for attr upgrade

Otherwise this is going to crash either the TypeFinder or the
Verifier.

[BitcodeReader] Support GEP without indices

LLVM considers these to be legal, so make sure the bitcode reader
can read them. I broke this when implementing opaque pointer
auto upgrade support.

Attributes: add a new allocalign attribute

This will let us start moving away from hard-coded attributes in
MemoryBuiltins.cpp and put the knowledge about various attribute
functions in the compiler

Attributes: add a new allocalign attribute

This will let us start moving away from hard-coded attributes in
MemoryBuiltins.cpp and put the knowledge about various attribute
functions in the compilers that emit those calls where it probably
belongs.

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

show more ...

[Bitcode] Move x86_intrcc upgrade to bitcode reader

This upgrade requires access the legacy pointer element type, so
it needs to happen inside the bitcode reader.

[Bitcode] Fully support opaque pointer auto upgrade

This completes the propagation of type IDs through bitcode reading,
and switches remaining uses of getPointerElementType() to use
contained type I

[Bitcode] Fully support opaque pointer auto upgrade

This completes the propagation of type IDs through bitcode reading,
and switches remaining uses of getPointerElementType() to use
contained type IDs.

The main new thing here is that sometimes we need to create a type
ID for a type that was not explicitly encoded in bitcode (or we
don't know its ID at the current point). For such types we create a
"virtual" type ID, which is cached based on the type and the
contained type IDs. Luckily, we generally only need zero or one
contained type IDs, and in the one case where we need two, we can
get away with not including it in the cache key.

With this change, we pass the entirety of llvm-test-suite at O3
with opaque pointers.

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

show more ...

[SanitizerBounds] Add support for NoSanitizeBounds function

Currently adding attribute no_sanitize("bounds") isn't disabling
-fsanitize=local-bounds (also enabled in -fsanitize=bounds). The Clang
fr

[SanitizerBounds] Add support for NoSanitizeBounds function

Currently adding attribute no_sanitize("bounds") isn't disabling
-fsanitize=local-bounds (also enabled in -fsanitize=bounds). The Clang
frontend handles fsanitize=array-bounds which can already be disabled by
no_sanitize("bounds"). However, instrumentation added by the
BoundsChecking pass in the middle-end cannot be disabled by the
attribute.

The fix is very similar to D102772 that added the ability to selectively
disable sanitizer pass on certain functions.

In this patch, if no_sanitize("bounds") is provided, an additional
function attribute (NoSanitizeBounds) is attached to IR to let the
BoundsChecking pass know we want to disable local-bounds checking. In
order to support this feature, the IR is extended (similar to D102772)
to make Clang able to preserve the information and let BoundsChecking
pass know bounds checking is disabled for certain function.

Reviewed By: melver

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

show more ...

[IR] Use CallBase::getParamElementType() (NFC)

As this method now exists on CallBase, use it rather than the
one on AttributeList.

[Bitcode] Store function type IDs rather than function types

This resolves one of the type ID propagation TODOs.

[Bitcode] Store type IDs for values

This is the next step towards supporting bitcode auto upgrade with
opaque pointers. The ValueList now stores the Value* together with
its associated type ID, whic

[Bitcode] Store type IDs for values

This is the next step towards supporting bitcode auto upgrade with
opaque pointers. The ValueList now stores the Value* together with
its associated type ID, which allows inspecting the original pointer
element type of arbitrary values.

This is a largely mechanical change threading the type ID through
various places. I've left TODOTypeID placeholders in a number of
places where determining the type ID is either non-trivial or
requires allocating a new type ID not present in the original
bitcode. For this reason, the new type IDs are also not used for
anything yet (apart from propagation). They will get used once the
TODOs are resolved.

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

show more ...

[BitcodeReader] Change order of assignValue() arguments (NFC)

Other methods in ValueList generally pass Idx first, and it is
more convention for assignment methods to have the target on the
LHS rath

[BitcodeReader] Change order of assignValue() arguments (NFC)

Other methods in ValueList generally pass Idx first, and it is
more convention for assignment methods to have the target on the
LHS rather than RHS.

show more ...

[Bitcode] Improve support for opaque-pointer bitcode upgrade

This is step two of supporting autoupgrade of old bitcode to opaque
pointers. Rather than tracking the element type ID of pointers in
par

[Bitcode] Improve support for opaque-pointer bitcode upgrade

This is step two of supporting autoupgrade of old bitcode to opaque
pointers. Rather than tracking the element type ID of pointers in
particular, track all type IDs that a type contains. This allows us
to recover the element type in more complex situations, e.g. when
we need to determine the pointer element type of a vector element
or function type parameter.

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

show more ...

[BitcodeReader] Fix use-after-move