A LazySymbol is one that lives in `.a` archive and gets pulled in by a
strong reference. However, weak references to such symbols do not
result in them be loaded from the archive. In this case we want to
treat such symbols at undefined rather then lazy, once symbols
resolution is complete.
This fixes a crash bug in the linker when weakly referenced symbol that
lives in an archive file is live at the end of the link. In the case of
dynamic linking this is expected to turn into an import with (in the
case of a function symbol) a function index.
Differential Revision: https://reviews.llvm.org/D130736
Fixing potential int overflow and uninitialized variables.
These were found by Coverity static code inspection.
Differential Revision: https://reviews.llvm.org/D130795
The table of contents in the HTML version of this doc takes up 25 pages
(in my browser, on my 4K monitor) and is too long for me to navigate
comfortably. And most of it is irrelevant detail like this:
- Bitwise Binary Operations
- 'shl' Instruction
- Syntax:
- Overview:
- Arguments:
- Semantics:
- Example:
- 'lshr' Instruction
- Syntax:
- Overview:
- Arguments:
- Semantics:
- Example:
Reducing the contents depth from 4 to 3 removes most of this detail,
leaving just a list of instructions, which only takes up 7 pages and I
find it much easier to navigate.
Incidentally the depth was set to 3 when this document was first
converted to reST and was only increased to 4 in what looks like an
accidental change: 080133453b
Differential Revision: https://reviews.llvm.org/D130635
This patch enables context-sensitive analysis of multiple different calls to the same function (see the `ContextSensitiveSetBothTrueAndFalse` example in the `TransferTest` suite) by replacing the `Environment` copy-assignment with a call to the new `popCall` method, which `std::move`s some fields but specifically does not move `DeclToLoc` and `ExprToLoc` from the callee back to the caller.
To enable this, the `StorageLocation` for a given parameter needs to be stable across different calls to the same function, so this patch also improves the modeling of parameter initialization, using `ReferenceValue` when necessary (for arguments passed by reference).
This approach explicitly does not work for recursive calls, because we currently only plan to use this context-sensitive machinery to support specialized analysis models we write, not analysis of arbitrary callees.
Reviewed By: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D130726
Instead of detecting `_Float16` support at CMake configuration time,
detect it at compile time by checking for the predefined (by the
compiler) macro `__FLT16_MAX__` instead.
This solves the issue where compiler-rt is built simultaneously for both
x86_64 and i386 targets, and the CMake configuration uses x86_64
compilation to detect `_Float16` support, while it may not be supported
by the i386 target (if it does not have SSE2).
While here, rename `COMPILERT_RT_HAS_FLOAT16` to `CRT_HAS_FLOAT16`, to
conform more to the naming style used in `int_lib.h` and `int_types.h`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D130718
It is not necessary to wait for all outstanding memory operations before
barriers on hardware that can back off of the barrier in the event of an
exception when traps are enabled. Add a new subtarget feature which
tracks which HW has this ability.
Reviewed By: #amdgpu, rampitec
Differential Revision: https://reviews.llvm.org/D130722
With the goal of reusing that handler to do other things besides
handling assertions (such as terminating when an exception is thrown
under -fno-exceptions), the name `__libcpp_assertion_handler` doesn't
really make sense anymore.
Furthermore, I didn't want to use the name `__libcpp_abort_handler`,
since that would give the impression that the handler is called
whenever `std::abort()` is called, which is not the case at all.
Differential Revision: https://reviews.llvm.org/D130562
After the intoduction of global destructor support, there is a possiblity to run invalid instructions in the destructor of Interpreter class. Completely disable tests in platforms with failing test cases.
Differential Revision: https://reviews.llvm.org/D130786
C99 6.7.4p2 clarifies that a function specifier can only be used in the
declaration of a function. _Noreturn is a function specifier, so it is
a constraint violation to write it on a structure or union field, but
we missed that case.
Fixes#56800
The implementation and API of GEP Op has gotten a bit convoluted over the time. Issues with it are:
* Misleading naming: `indices` actually only contains the dynamic indices, not all of them. To get the amount of indices you need to query the size of `structIndices`
* Very difficult to iterate over all indices properly: One had to iterate over `structIndices`, check whether it contains the magic constant `kDynamicIndex`, if it does, access the next value in `index` etc.
* Inconvenient to build: One either has create lots of constant ops for every index or have an odd split of passing both a `ValueRange` as well as a `ArrayRef<int32_t>` filled with `kDynamicIndex` at the correct places.
* Implementation doing verification in the build method
and more.
This patch attempts to address all these issues via convenience classes and reworking the way GEP Op works:
* Adds `GEPArg` class which is a sum type of a `int32_t` and `Value` and is used to have a single convenient easy to use `ArrayRef<GEPArg>` in the builders instead of the previous `ValueRange` + `ArrayRef<int32_t>` builders.
* Adds `GEPIndicesAdapter` which is a class used for easy random access and iteration over the indices of a GEP. It is generic and flexible enough to also instead return eg. a corresponding `Attribute` for an operand inside of `fold`.
* Rename `structIndices` to `rawConstantIndices` and `indices` to `dynamicIndices`: `rawConstantIndices` signifies one shouldn't access it directly as it is encoded, and `dynamicIndices` is more accurate and also frees up the `indices` name.
* Add `getIndices` returning a `GEPIndicesAdapter` to easily iterate over the GEP Ops indices.
* Move the verification/asserts out of the build method and into the `verify` method emitting op error messages.
* Add convenient builder methods making use of `GEPArg`.
* Add canonicalizer turning dynamic indices with constant values into constant indices to have a canonical representation.
The only breaking change is for any users building GEPOps that have so far used the old `ValueRange` + `ArrayRef<int32_t>` builder as well as those using the generic syntax.
Another follow up patch then goes through upstream and makes use of the new `ArrayRef<GEPArg>` builder to remove a lot of code building constants for GEP indices.
Differential Revision: https://reviews.llvm.org/D130730
Similarly to -o output directories will not be created so -Map being
copied verbatim will likely cause ld.lld @response.txt to fail.
Differential Revision: https://reviews.llvm.org/D130681
Adding complex value with 0 for real and imaginary part can be ignored.
NOTE: This type of canonicalization can be written in an easy and tidy format using `complex.number` after constant op supports custom attribute.
Differential Revision: https://reviews.llvm.org/D130748
https://alive2.llvm.org/ce/z/3jYbEH
We should choose one of these forms, and the option that uses
the narrow type allows the motivating example from issue #56294
to reduce. In the best case (no 'not' needed and 'trunc' remains),
this does remove an instruction.
Note that there is what looks like a regression because there
is an existing canonicalization that turns trunc into and+icmp.
That is a long-standing transform, and I'm not sure what effect
reversing it would have.
A group of functions in the Affine dialect provides a mechanism for
buliding folded-by-construction operations. These functions used to
accept a `RewriterBase` reference because they may need to erase the
operations that were folded and notify the rewriter when called from
rewrite patterns. Adopt a different approach: postpone the builder
notification of the op creation until we are certain that the op will
not be folded away. This removes the need to notify the rewriter about
op deletion following op construction in case of successful folding, and
removes a bunch of one-off `IRRewriter` instances in transform code that
may mess up insertion points.
Reviewed By: springerm, mravishankar
Differential Revision: https://reviews.llvm.org/D130616
isAllowedInitiallyIDChar is only used with non-ASCII codepoints,
which are handled by isAsciiIdentifierStart.
To make that clearer, remove the check for _ from
isAllowedInitiallyIDChar, and assert on ASCII - to ensure neither
_ or $ are passed to this function.
Reviewed By: tahonermann, aaron.ballman
Differential Revision: https://reviews.llvm.org/D130750
If the LHS op has a single use then using the more general AND op is likely to allow commutation, load folding, generic folds etc.
Updated version - original version rG057db2002bb3 didn't correctly account for multiple uses of the mask that might be folding "OR(AND(X,C),AND(Y,~C)) -> OR(AND(X,C),ANDNP(C,Y))" in canonicalizeBitSelect
Previously, it was necessary to check the atomics lowering or expansion
code to determine which argument was which.
This patch additionally tweaks the documentation comment in
TargetLowering to clarify the return value of the intrinsic and that the
intrinsic isn't required to mask and shift the result (this is handled
by the target-independent code in AtomicExpandPass).
This review is extracted from D96035.
DWARF Debuginfo classes have two representations for DIEs: DWARFDebugInfoEntry
(short) and DWARFDie(extended). Depending on the task, it might be more convenient
to use DWARFDebugInfoEntry or/and DWARFDie. DWARFUnit class already has methods
working with DWARFDie and DWARFDebugInfoEntry. This patch adds more
methods working with DWARFDebugInfoEntry to have paired functionality.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D126059
When constant folding "ANDNP(C,X) -> AND(~C,X)" we hit cases such as this where we interfered with the "OR(AND(X,C),AND(Y,~C)) -> OR(AND(X,C),ANDNP(C,Y))" fold in canonicalizeBitSelect
Since 814a0abcce, this would break if we
had a function in the module that becomes dead in any codegen IR
pass. The function wasn't deleted since it was initially used in dead
code, but is detached from the call graph and doesn't appear in the PO
traversal. Do a second walk over the module to populate the resources
of any functions which weren't already processed.
If the subregister uses were dead, this would leave the main range
segment pointing to a deleted instruction.
Not sure if this should try to avoid shrinking if we know we don't
have dead components.
In preperation of the deferred instantation progress, this patch
propagates the multi-level template argument lists further through the
API to reduce the size of that patch.
Since D92241, compiler-rt/cmake/builtin-config-ix.cmake automatically tests
the host compiler for support of _Float16 and conditionally defines
COMPILER_RT_HAS_FLOAT16. That defines the macro while the compiler-rt
builtins are being built. To also define it during the compiler-rt test
runs requires whitelisting the architecture in
compiler-rt/test/builtins/CMakeLists.txt, as done in this patch. That seems
brittle. Ideally, we'd move to a solution where the target compiler was
automatically tested as well, but I'm not sure how feasible that is with the
current CMake setup.
For now, this patch whitelists RISC-V, fixing errors in test__extendhfsf2.
Alternate solutions that fix the root issue are welcome, though.
Differential Revision: https://reviews.llvm.org/D129432
Sam Clegg