History log of /llvm-project/llvm/lib/Transforms/Utils/Evaluator.cpp (Results 1 – 25 of 60)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


123