[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

Extend the `uwtable` attribute with unwind table kind

We have the `clang -cc1` command-line option `-funwind-tables=1|2` and
the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind
tabl

Extend the `uwtable` attribute with unwind table kind

We have the `clang -cc1` command-line option `-funwind-tables=1|2` and
the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind
tables (1) or asynchronous unwind tables (2)`. However, this is
encoded in LLVM IR by the presence or the absence of the `uwtable`
attribute, i.e. we lose the information whether to generate want just
some unwind tables or asynchronous unwind tables.

Asynchronous unwind tables take more space in the runtime image, I'd
estimate something like 80-90% more, as the difference is adding
roughly the same number of CFI directives as for prologues, only a bit
simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even
more, if you consider tail duplication of epilogue blocks.
Asynchronous unwind tables could also restrict code generation to
having only a finite number of frame pointer adjustments (an example
of *not* having a finite number of `SP` adjustments is on AArch64 when
untagging the stack (MTE) in some cases the compiler can modify `SP`
in a loop).
Having the CFI precise up to an instruction generally also means one
cannot bundle together CFI instructions once the prologue is done,
they need to be interspersed with ordinary instructions, which means
extra `DW_CFA_advance_loc` commands, further increasing the unwind
tables size.

That is to say, async unwind tables impose a non-negligible overhead,
yet for the most common use cases (like C++ exceptions), they are not
even needed.

This patch extends the `uwtable` attribute with an optional
value:
- `uwtable` (default to `async`)
- `uwtable(sync)`, synchronous unwind tables
- `uwtable(async)`, asynchronous (instruction precise) unwind tables

Reviewed By: MaskRay

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

show more ...

[BitcodeReader] Rename method for element type by ID (NFC)

Make it clearer that this method is specifically for pointer
element types, and not other element types. This distinction will
be relevant

[BitcodeReader] Rename method for element type by ID (NFC)

Make it clearer that this method is specifically for pointer
element types, and not other element types. This distinction will
be relevant in the future.

The somewhat unusual spelling is to make sure this does not show
up when grepping for getPointerElementType.

show more ...

[Bitcode] Add partial support for opaque pointer auto-upgrade

Auto-upgrades that rely on the pointer element type do not work in
opaque pointer mode. The idea behind this patch is that we can
instea

[Bitcode] Add partial support for opaque pointer auto-upgrade

Auto-upgrades that rely on the pointer element type do not work in
opaque pointer mode. The idea behind this patch is that we can
instead work with type IDs, for which we can retain the pointer
element type. For typed pointer bitcode, we will have a distinct
type ID for pointers with distinct element type, even if there will
only be a single corresponding opaque pointer type.

The disclaimer here is that this is only the first step of the change,
and there are still more getPointerElementType() calls to remove.
I expect that two more patches will be needed:
1. Track all "contained" type IDs, which will allow us to handle
function params (which are contained in the function type) and GEPs
(which may use vectors of pointers)
2. Track type IDs for values, which is e.g. necessary to handle loads.

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

show more ...

[Bitcode] Check minimum size of constant GEP record

Checking this early, because we may end up reading up to two
records before the operands.