Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6 |
|
#
5013c81b |
| 12-Dec-2024 |
Nikita Popov <npopov@redhat.com> |
[GlobalOpt][Evaluator] Don't evaluate calls with signature mismatch (#119548)
The global ctor evaluator tries to evalute function calls where the call
function type and function type do not match,
[GlobalOpt][Evaluator] Don't evaluate calls with signature mismatch (#119548)
The global ctor evaluator tries to evalute function calls where the call
function type and function type do not match, by performing bitcasts.
This currently causes a crash when calling a void function with non-void
return type.
I've opted to remove this functionality entirely rather than fixing this
specific case. With opaque pointers, there shouldn't be a legitimate use
case for this anymore, as we don't need to look through pointer type
casts. Doing other bitcasts is very iffy because it ignores ABI
considerations. We should at least leave adjusting the signatures to
make them line up to InstCombine (which also does some iffy things, but
is at least somewhat more constrained).
Fixes https://github.com/llvm/llvm-project/issues/118725.
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
013f4a46 |
| 05-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Utils] Remove unused includes (NFC) (#114748)
Identified with misc-include-cleaner.
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2 |
|
#
a722e236 |
| 18-Apr-2023 |
Nikita Popov <npopov@redhat.com> |
[GlobalOpt] Don't evaluate large memset (PR62191)
If the memset is large, checking every single byte of the global may be very slow. Add an upper bound on the size of memset we handle.
For the comm
[GlobalOpt] Don't evaluate large memset (PR62191)
If the memset is large, checking every single byte of the global may be very slow. Add an upper bound on the size of memset we handle.
For the common special case of memset zeroinitializer to zero, add a fastpath that checks just that and is not length limited.
Fixes https://github.com/llvm/llvm-project/issues/62191.
show more ...
|
#
7021182d |
| 16-Apr-2023 |
Shraiysh Vaishay <shraiysh@gmail.com> |
[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 ...
|
Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
89fae41e |
| 05-Dec-2022 |
Fangrui Song <i@maskray.me> |
[IR] llvm::Optional => std::optional
Many llvm/IR/* files have been migrated by other contributors. This migrates most remaining files.
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0 |
|
#
b18ff9c4 |
| 28-Aug-2022 |
Kazu Hirata <kazu@google.com> |
[Transform] Use range-based for loops (NFC)
|
Revision tags: llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
e9afdf83 |
| 21-Jul-2022 |
Alexander Shaposhnikov <ashaposhnikov@google.com> |
[GlobalOpt] Enable evaluation of atomic loads
Relax the check to allow evaluation of atomic loads (but still skip volatile loads).
Test plan: 1/ ninja check-llvm check-clang 2/ Bootstrapped LLVM/Cl
[GlobalOpt] Enable evaluation of atomic loads
Relax the check to allow evaluation of atomic loads (but still skip volatile loads).
Test plan: 1/ ninja check-llvm check-clang 2/ Bootstrapped LLVM/Clang pass tests
Differential revision: https://reviews.llvm.org/D130211
show more ...
|
#
67f1fe85 |
| 20-Jul-2022 |
Alexander Shaposhnikov <ashaposhnikov@google.com> |
[GlobalOpt] Enable evaluation of atomic stores
Relax the check to allow evaluation of atomic stores (but still skip volatile stores).
Test plan: 1/ ninja check-llvm check-clang 2/ Bootstrapped LLVM
[GlobalOpt] Enable evaluation of atomic stores
Relax the check to allow evaluation of atomic stores (but still skip volatile stores).
Test plan: 1/ ninja check-llvm check-clang 2/ Bootstrapped LLVM/Clang pass tests
Differential revision: https://reviews.llvm.org/D129841
show more ...
|
#
1579fc62 |
| 30-Jun-2022 |
Nikita Popov <npopov@redhat.com> |
[Evaluator] Add missing LLVM_DEBUG()
Missed these in 41f0b6a78143776d673565cfa830849e3b468b8e, resulting in unconditional debug output.
|
#
41f0b6a7 |
| 30-Jun-2022 |
Nikita Popov <npopov@redhat.com> |
[Evaluator] Use ConstantFoldInstOperands()
For instructions that don't need any special handling, use ConstantFoldInstOperands(), rather than re-implementing individual cases.
This is probably not
[Evaluator] Use ConstantFoldInstOperands()
For instructions that don't need any special handling, use ConstantFoldInstOperands(), rather than re-implementing individual cases.
This is probably not NFC because it can handle cases the previous code missed (e.g. vector operations).
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
#
5548e807 |
| 17-May-2022 |
Nikita Popov <npopov@redhat.com> |
[IR] Remove support for extractvalue constant expression
This removes the extractvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. extrac
[IR] Remove support for extractvalue constant expression
This removes the extractvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. extractvalue is already not supported in bitcode, so we do not need to worry about bitcode auto-upgrade.
Uses of ConstantExpr::getExtractValue() should be replaced with IRBuilder::CreateExtractValue() (if the fact that the result is constant is not important) or ConstantFoldExtractValueInstruction() (if it is). Though for this particular case, it is also possible and usually preferable to use getAggregateElement() instead.
The C API function LLVMConstExtractValue() is removed, as the underlying constant expression no longer exists. Instead, LLVMBuildExtractValue() should be used (which will constant fold or create an instruction). Depending on the use-case, LLVMGetAggregateElement() may also be used instead.
Differential Revision: https://reviews.llvm.org/D125795
show more ...
|
#
f65c88c4 |
| 24-Jun-2022 |
Nikita Popov <npopov@redhat.com> |
[GlobalOpt] Fix memset handling in global ctor evaluation (PR55859)
The global ctor evaluator currently handles by checking whether the memset memory is already zero, and skips it in that case. Howe
[GlobalOpt] Fix memset handling in global ctor evaluation (PR55859)
The global ctor evaluator currently handles by checking whether the memset memory is already zero, and skips it in that case. However, it only actually checks the first byte of the memory being set.
This patch extends the code to check all bytes being set. This is done byte-by-byte to avoid converting undef values to zeros in larger reads. However, the handling is still not completely correct, because there might still be padding bytes (though probably this doesn't matter much in practice, as I'd expect global variable padding to be zero-initialized in practice).
Mostly fixes https://github.com/llvm/llvm-project/issues/55859.
Differential Revision: https://reviews.llvm.org/D128532
show more ...
|
Revision tags: llvmorg-14.0.3 |
|
#
4e652918 |
| 27-Apr-2022 |
Arthur Eubanks <aeubanks@google.com> |
[OpaquePtr][GlobalOpt] Don't attempt to evaluate global constructors with arguments
Previously all entries in global_ctors had to have the void()* type and we'd skip evaluating bitcasted functions.
[OpaquePtr][GlobalOpt] Don't attempt to evaluate global constructors with arguments
Previously all entries in global_ctors had to have the void()* type and we'd skip evaluating bitcasted functions. With opaque pointers we may see the function directly.
Fixes #55147.
Reviewed By: #opaque-pointers, nikic
Differential Revision: https://reviews.llvm.org/D124553
show more ...
|
Revision tags: llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
#
a494ae43 |
| 01-Mar-2022 |
serge-sans-paille <sguelton@redhat.com> |
Cleanup includes: TransformsUtils
Estimation on the impact on preprocessor output: before: 1065307662 after: 1064800684
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-
Cleanup includes: TransformsUtils
Estimation on the impact on preprocessor output: before: 1065307662 after: 1064800684
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120741
show more ...
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
6a008de8 |
| 25-Jan-2022 |
Nikita Popov <npopov@redhat.com> |
[Evaluator] Simplify handling of bitcasted calls
When fetching the function, strip casts. When casting the result, use the call result type. Don't actually inspect the bitcast.
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
6e474d33 |
| 05-Jan-2022 |
Nikita Popov <npopov@redhat.com> |
[GlobalOpt][Evaluator] Fix off by one error in bounds check (PR53002)
We should bail out if the index is >= the size, not > the size.
Fixes https://github.com/llvm/llvm-project/issues/53002.
|
#
787f86e6 |
| 05-Jan-2022 |
Nikita Popov <npopov@redhat.com> |
[GlobalOpt][Evaluator] Don't create bitcast for same type (PR52994)
isBitOrNoopPointerCastable() returns true if the types are the same, but it's not actually possible to create a bitcast for all su
[GlobalOpt][Evaluator] Don't create bitcast for same type (PR52994)
isBitOrNoopPointerCastable() returns true if the types are the same, but it's not actually possible to create a bitcast for all such types. The assumption seems to be that the user will omit creating the cast in that case, as it is unnecessary.
Fixes https://github.com/llvm/llvm-project/issues/52994.
show more ...
|
#
bbeaf2aa |
| 09-Dec-2021 |
Nikita Popov <npopov@redhat.com> |
[GlobalOpt][Evaluator] Rewrite global ctor evaluation (fixes PR51879)
Global ctor evaluation currently models memory as a map from Constant* to Constant*. For this to be correct, it is required that
[GlobalOpt][Evaluator] Rewrite global ctor evaluation (fixes PR51879)
Global ctor evaluation currently models memory as a map from Constant* to Constant*. For this to be correct, it is required that there is only a single Constant* referencing a given memory location. The Evaluator tries to ensure this by imposing certain limitations that could result in ambiguities (by limiting types, casts and GEP formats), but ultimately still fails, as can be seen in PR51879. The approach is fundamentally fragile and will get more so with opaque pointers.
My original thought was to instead store memory for each global as an offset => value representation. However, we also need to make sure that we can actually rematerialize the modified global initializer into a Constant in the end, which may not be possible if we allow arbitrary writes.
What this patch does instead is to represent globals as a MutableValue, which is either a Constant* or a MutableAggregate*. The mutable aggregate exists to allow efficient mutation of individual aggregate elements, as mutating an element on a Constant would require interning a new constant. When a write to the Constant* is made, it is converted into a MutableAggregate* as needed.
I believe this should make the evaluator more robust, compatible with opaque pointers, and a bit simpler as well.
Fixes https://github.com/llvm/llvm-project/issues/51221.
Differential Revision: https://reviews.llvm.org/D115530
show more ...
|
Revision tags: llvmorg-13.0.1-rc1 |
|
#
d1abf481 |
| 20-Nov-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use range-based for loops (NFC)
|
#
0425ea46 |
| 18-Nov-2021 |
Senran Zhang <zsrkmyn@gmail.com> |
[NFC][OpaquePtr][Evaluator] Remove call to PointerType::getElementType
There are still another 2 uses of PointerType::getElementType in Evaluator when evaluating BitCast's on pointers. BitCast's on
[NFC][OpaquePtr][Evaluator] Remove call to PointerType::getElementType
There are still another 2 uses of PointerType::getElementType in Evaluator when evaluating BitCast's on pointers. BitCast's on pointers should be removed when opaque ptr is ready, so I just keep them as is.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D114131
show more ...
|
#
4f0225f6 |
| 01-Oct-2021 |
Kazu Hirata <kazu@google.com> |
[Transforms] Migrate from getNumArgOperands to arg_size (NFC)
Note that getNumArgOperands is considered a legacy name. See llvm/include/llvm/IR/InstrTypes.h for details.
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
d1431030 |
| 12-Jul-2021 |
Jon Roelofs <jonathan_roelofs@apple.com> |
[GlobalOpt] Fix a miscompile when evaluating struct initializers.
The bug was that evaluateBitcastFromPtr attempts a narrowing to a struct's 0th element of a store that covers other elements. While
[GlobalOpt] Fix a miscompile when evaluating struct initializers.
The bug was that evaluateBitcastFromPtr attempts a narrowing to a struct's 0th element of a store that covers other elements. While this is okay on the load side, applying it to stores causes us to miss the writes to the additionally covered elements.
rdar://79503568
Differential revision: https://reviews.llvm.org/D105838
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
b606e2df |
| 21-Apr-2021 |
Arthur Eubanks <aeubanks@google.com> |
[Evaluator] Bitcast result of pointer stripping
Trying to evaluate a GEP would assert with "Ty == cast<PointerType>(C->getType()->getScalarType())->getElementType()" because the type of the pointe
[Evaluator] Bitcast result of pointer stripping
Trying to evaluate a GEP would assert with "Ty == cast<PointerType>(C->getType()->getScalarType())->getElementType()" because the type of the pointer we would evaluate the GEP argument to would be a different type than the GEP was expecting. We should treat pointer stripping as a bitcast.
The test adds a redundant GEP that would crash due to type mismatch.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D100970
show more ...
|
#
5e71b9fa |
| 18-Apr-2021 |
Arthur Eubanks <aeubanks@google.com> |
Explicitly pass type to cast load constant folding result
Previously we would use the type of the pointee to determine what to cast the result of constant folding a load. To aid with opaque pointer
Explicitly pass type to cast load constant folding result
Previously we would use the type of the pointee to determine what to cast the result of constant folding a load. To aid with opaque pointer types, we should explicitly pass the type of the load rather than looking at pointee types.
ConstantFoldLoadThroughBitcast() converts the const prop'd value to the proper load type (e.g. [1 x i32] -> i32). Instead of calling this in every intermediate step like bitcasts, we only call this when we actually see the global initializer value.
In some existing uses of this API, we don't know the exact type we're loading from immediately (e.g. first we visit a bitcast, then we visit the load using the bitcast). In those cases we have to manually call ConstantFoldLoadThroughBitcast() when simplifying the load to make sure that we cast to the proper type.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D100718
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
a8ab1f98 |
| 18-Mar-2021 |
Arthur Eubanks <aeubanks@google.com> |
[Evaluator] Look through invariant.group intrinsics
Turning on -fstrict-vtable-pointers in Chrome caused an extra global initializer. Turns out that a llvm.strip.invariant.group intrinsic was causin
[Evaluator] Look through invariant.group intrinsics
Turning on -fstrict-vtable-pointers in Chrome caused an extra global initializer. Turns out that a llvm.strip.invariant.group intrinsic was causing GlobalOpt to fail to step through some simple code.
We can treat *.invariant.group uses as simply their operand. Value::stripPointerCastsForAliasAnalysis() does exactly this. This should be safe because the Evaluator does not skip memory accesses due to invariants or alias analysis.
However, we don't want to leak that we've stripped arbitrary pointer casts to users of Evaluator, so we bail out if we evaluate a function to any constant, since we may have looked through *.invariant.group calls and aliasing pointers cannot be arbitrarily substituted.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D98843
show more ...
|