History log of /llvm-project/llvm/lib/Transforms/Scalar/JumpThreading.cpp (Results 1 – 25 of 567)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# e45de3db 22-Jan-2025 William Huang <williamjhuang@google.com>

Move RemoveRedundantDbgInstrs outside of inner loop in JumpThreading (#123008)

This cleanup action only needs to be performed once when the entire
optimization is converged. Doing it in every itera

Move RemoveRedundantDbgInstrs outside of inner loop in JumpThreading (#123008)

This cleanup action only needs to be performed once when the entire
optimization is converged. Doing it in every iteration has a very high
time-complexity, as it queries every dbg value in a dense map

Compare before and after for one internal source file with many basic
blocks


![image](https://github.com/user-attachments/assets/1dac76a9-a974-4068-9aa1-4041f963fa8e)

![image](https://github.com/user-attachments/assets/73ea2ef1-d1f4-4064-8826-8c13fb539b8d)

>90% reduction in this extreme case.

show more ...


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6
# 4a0d53a0 13-Dec-2024 Ramkumar Ramachandra <ramkumar.ramachandra@codasip.com>

PatternMatch: migrate to CmpPredicate (#118534)

With the introduction of CmpPredicate in 51a895a (IR: introduce struct
with CmpInst::Predicate and samesign), PatternMatch is one of the first
key p

PatternMatch: migrate to CmpPredicate (#118534)

With the introduction of CmpPredicate in 51a895a (IR: introduce struct
with CmpInst::Predicate and samesign), PatternMatch is one of the first
key pieces of infrastructure that must be updated to match a CmpInst
respecting samesign information. Implement this change to Cmp-matchers.

This is a preparatory step in migrating the codebase over to
CmpPredicate. Since we no functional changes are desired at this stage,
we have chosen not to migrate CmpPredicate::operator==(CmpPredicate)
calls to use CmpPredicate::getMatching(), as that would have visible
impact on tests that are not yet written: instead, we call
CmpPredicate::operator==(Predicate), preserving the old behavior, while
also inserting a few FIXME comments for follow-ups.

show more ...


Revision tags: llvmorg-19.1.5, llvmorg-19.1.4
# 4048c643 12-Nov-2024 Kazu Hirata <kazu@google.com>

[llvm] Remove redundant control flow statements (NFC) (#115831)

Identified with readability-redundant-control-flow.


# 94f9cbbe 02-Nov-2024 Kazu Hirata <kazu@google.com>

[Scalar] Remove unused includes (NFC) (#114645)

Identified with misc-include-cleaner.


Revision tags: llvmorg-19.1.3
# 6924fc03 16-Oct-2024 Rahul Joshi <rjoshi@nvidia.com>

[LLVM] Add `Intrinsic::getDeclarationIfExists` (#112428)

Add `Intrinsic::getDeclarationIfExists` to lookup an existing
declaration of an intrinsic in a `Module`.


Revision tags: 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
# 79d6f52c 04-Jul-2024 Nikita Popov <npopov@redhat.com>

[LVI] Use Constant instead of Tristate for predicate results

A lot of the users just end up converting it into a Constant
themselves. Doing this in the API leaves less room for error
with vector typ

[LVI] Use Constant instead of Tristate for predicate results

A lot of the users just end up converting it into a Constant
themselves. Doing this in the API leaves less room for error
with vector types, and brings getPredicateResult() closer to
LatticeValueElement::getCompare(), hopefully allowing us to
consolidate them.

show more ...


# 37661a17 01-Jul-2024 Shan Huang <52285902006@stu.ecnu.edu.cn>

[DebugInfo][JumpThreading] Fix missing debug location updates for br instructions (#96889)

Fix #96885 .


# 2d209d96 27-Jun-2024 Nikita Popov <npopov@redhat.com>

[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)

This is a helper to avoid writing `getModule()->getDataLayout()`. I
regularly try to use this method only to remember it does

[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)

This is a helper to avoid writing `getModule()->getDataLayout()`. I
regularly try to use this method only to remember it doesn't exist...

`getModule()->getDataLayout()` is also a common (the most common?)
reason why code has to include the Module.h header.

show more ...


# f05b15b2 15-Jun-2024 Kazu Hirata <kazu@google.com>

[JumpThreading] Use SmallPtrSet (NFC) (#95674)

The use of SmallPtrSet here saves 0.66% of heap allocations during
the compilation of a large preprocessed file, namely
X86ISelLowering.cpp, for the

[JumpThreading] Use SmallPtrSet (NFC) (#95674)

The use of SmallPtrSet here saves 0.66% of heap allocations during
the compilation of a large preprocessed file, namely
X86ISelLowering.cpp, for the X86 target.

show more ...


Revision tags: llvmorg-18.1.8
# 294f3ce5 12-Jun-2024 Paul Kirth <paulkirth@google.com>

Reapply "[llvm][IR] Extend BranchWeightMetadata to track provenance o… (#95281)

…f weights" #95136

Reverts #95060, and relands #86609, with the unintended code generation
changes addressed.

T

Reapply "[llvm][IR] Extend BranchWeightMetadata to track provenance o… (#95281)

…f weights" #95136

Reverts #95060, and relands #86609, with the unintended code generation
changes addressed.

This patch implements the changes to LLVM IR discussed in
https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032

In this patch, we add an optional field to MD_prof meatdata nodes for
branch weights, which can be used to distinguish weights added from
llvm.expect* intrinsics from those added via other methods, e.g. from
profiles or inserted by the compiler.

One of the major motivations, is for use with MisExpect diagnostics,
which need to know if branch_weight metadata originates from an
llvm.expect intrinsic. Without that information, we end up checking
branch weights multiple times in the case if ThinLTO + SampleProfiling,
leading to some inaccuracy in how we report MisExpect related
diagnostics to users.

Since we change the format of MD_prof metadata in a fundamental way, we
need to update code handling branch weights in a number of places.

We also update the lang ref for branch weights to reflect the change.

show more ...


# 607afa0b 11-Jun-2024 Paul Kirth <paulkirth@google.com>

Revert "[llvm][IR] Extend BranchWeightMetadata to track provenance of weights" (#95060)

Reverts llvm/llvm-project#86609

This change causes compile-time regressions for stage2 builds
(https://llv

Revert "[llvm][IR] Extend BranchWeightMetadata to track provenance of weights" (#95060)

Reverts llvm/llvm-project#86609

This change causes compile-time regressions for stage2 builds
(https://llvm-compile-time-tracker.com/compare.php?from=3254f31a66263ea9647c9547f1531c3123444fcd&to=c5978f1eb5eeca8610b9dfce1fcbf1f473911cd8&stat=instructions:u).
It also introduced unintended changes to `.text` which should be
addressed before relanding.

show more ...


# c5978f1e 10-Jun-2024 Paul Kirth <paulkirth@google.com>

[llvm][IR] Extend BranchWeightMetadata to track provenance of weights (#86609)

This patch implements the changes to LLVM IR discussed in

https://discourse.llvm.org/t/rfc-update-branch-weights-met

[llvm][IR] Extend BranchWeightMetadata to track provenance of weights (#86609)

This patch implements the changes to LLVM IR discussed in

https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032

In this patch, we add an optional field to MD_prof metadata nodes for
branch weights, which can be used to distinguish weights added from
`llvm.expect*` intrinsics from those added via other methods, e.g.
from profiles or inserted by the compiler.

One of the major motivations, is for use with MisExpect diagnostics,
which need to know if branch_weight metadata originates from an
llvm.expect intrinsic. Without that information, we end up checking
branch weights multiple times in the case if ThinLTO + SampleProfiling,
leading to some inaccuracy in how we report MisExpect related
diagnostics to users.

Since we change the format of MD_prof metadata in a fundamental way, we
need to update code handling branch weights in a number of places.

We also update the lang ref for branch weights to reflect the change.

show more ...


Revision tags: llvmorg-18.1.7, llvmorg-18.1.6
# 3773191f 11-May-2024 Shan Huang <52285902006@stu.ecnu.edu.cn>

[DebugInfo][JumpThreading] Fix missing debug location updates (#91581)


# f893dccb 09-May-2024 Eli Friedman <efriedma@quicinc.com>

Replace uses of ConstantExpr::getCompare. (#91558)

Use ICmpInst::compare() where possible, ConstantFoldCompareInstOperands
in other places. This only changes places where the either the fold is
gu

Replace uses of ConstantExpr::getCompare. (#91558)

Use ICmpInst::compare() where possible, ConstantFoldCompareInstOperands
in other places. This only changes places where the either the fold is
guaranteed to succeed, or the code doesn't use the resulting compare if
we fail to fold.

show more ...


Revision tags: llvmorg-18.1.5
# 7696d36b 26-Apr-2024 Carlos Alberto Enciso <Carlos.Enciso@sony.com>

[Transforms] Debug values are not remapped when cloning. (#87747)

When cloning instructions from one basic block to another,
the debug values are not remapped, in the same was as the
normal instru

[Transforms] Debug values are not remapped when cloning. (#87747)

When cloning instructions from one basic block to another,
the debug values are not remapped, in the same was as the
normal instructions.

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3
# 75dfa58e 20-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Rename DPMarker->DbgMarker (#85931)

Another trivial rename patch, the last big one for now, which renamed
DPMarkers to DbgMarkers. This required the field `DbgMarker` in
`Instruct

[RemoveDIs][NFC] Rename DPMarker->DbgMarker (#85931)

Another trivial rename patch, the last big one for now, which renamed
DPMarkers to DbgMarkers. This required the field `DbgMarker` in
`Instruction` to be renamed to `DebugMarker` to avoid a clash, but
otherwise was a simple string substitution of `s/DPMarker/DbgMarker` and
a manual renaming of `DPM` to `DM` in the few places where that acronym
was used for debug markers.

show more ...


Revision tags: llvmorg-18.1.2
# ffd08c77 19-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which re

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:

- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.

Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:

```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```

Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.

show more ...


# 2e865353 14-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Move DPValue::filter -> filterDbgVars (#85208)

This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPV

[RemoveDIs][NFC] Move DPValue::filter -> filterDbgVars (#85208)

This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPValue is about to change to DbgVariableRecord, which will result in
every `for` loop that uses DPValue::filter to require a line break. This
is a small thing, but it makes the rename patch more difficult to
review, and is just generally more awkward for what is a fairly common
loop. Secondly, the intent is to later break up the DPValue class into
subclasses, at which point it would be better to have a non-member
function that allows template arguments for the cases we want to filter
with greater specificity.

show more ...


# 15f3f446 12-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Rename common interface functions for DPValues->DbgRecords (#84793)

As part of the effort to rename the DbgRecord classes, this patch
renames the widely-used functions that operate

[RemoveDIs][NFC] Rename common interface functions for DPValues->DbgRecords (#84793)

As part of the effort to rename the DbgRecord classes, this patch
renames the widely-used functions that operate on DbgRecords but refer
to DbgValues or DPValues in their names to refer to DbgRecords instead;
all such functions are defined in one of `BasicBlock.h`,
`Instruction.h`, and `DebugProgramInstruction.h`.

This patch explicitly does not change the names of any comments or
variables, except for where they use the exact name of one of the
renamed functions. The reason for this is reviewability; this patch can
be trivially examined to determine that the only changes are direct
string substitutions and any results from clang-format responding to the
changed line lengths. Future patches will cover renaming variables and
comments, and then renaming the classes themselves.

show more ...


# fab2bb8b 11-Mar-2024 Justin Lebar <justin.lebar@gmail.com>

Add llvm::min/max_element and use it in llvm/ and mlir/ directories. (#84678)

For some reason this was missing from STLExtras.


Revision tags: llvmorg-18.1.1
# 2fe81ede 04-Mar-2024 Jeremy Morse <jeremy.morse@sony.com>

[NFC][RemoveDIs] Insert instruction using iterators in Transforms/

As part of the RemoveDIs project we need LLVM to insert instructions using
iterators wherever possible, so that the iterators can c

[NFC][RemoveDIs] Insert instruction using iterators in Transforms/

As part of the RemoveDIs project we need LLVM to insert instructions using
iterators wherever possible, so that the iterators can carry a bit of
debug-info. This commit implements some of that by updating the contents of
llvm/lib/Transforms/Utils to always use iterator-versions of instruction
constructors.

There are two general flavours of update:
* Almost all call-sites just call getIterator on an instruction
* Several make use of an existing iterator (scenarios where the code is
actually significant for debug-info)
The underlying logic is that any call to getFirstInsertionPt or similar
APIs that identify the start of a block need to have that iterator passed
directly to the insertion function, without being converted to a bare
Instruction pointer along the way.

Noteworthy changes:
* FindInsertedValue now takes an optional iterator rather than an
instruction pointer, as we need to always insert with iterators,
* I've added a few iterator-taking versions of some value-tracking and
DomTree methods -- they just unwrap the iterator. These are purely
convenience methods to avoid extra syntax in some passes.
* A few calls to getNextNode become std::next instead (to keep in the
theme of using iterators for positions),
* SeparateConstOffsetFromGEP has it's insertion-position field changed.
Noteworthy because it's not a purely localised spelling change.

All this should be NFC.

show more ...


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3
# ababa964 20-Feb-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[RemoveDIs][NFC] Introduce DbgRecord base class [1/3] (#78252)

Patch 1 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds a new base class

-> 1. Add DbgRecord

[RemoveDIs][NFC] Introduce DbgRecord base class [1/3] (#78252)

Patch 1 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds a new base class

-> 1. Add DbgRecord base class for DPValue and the not-yet-added
DPLabel class.
2. Add the DPLabel class.
3. Enable dbg.label conversion and add support to passes.

Patches 1 and 2 are NFC.

In the near future we also will rename DPValue to DbgVariableRecord and
DPLabel to DbgLabelRecord, at which point we'll overhaul the function
names too. The name DPLabel keeps things consistent for now.

show more ...


Revision tags: llvmorg-18.1.0-rc2
# 4f32f5d5 31-Jan-2024 Nikita Popov <npopov@redhat.com>

[AA][JumpThreading] Don't use DomTree for AA in JumpThreading (#79294)

JumpThreading may perform AA queries while the dominator tree is not up
to date, which may result in miscompilations.

Fix t

[AA][JumpThreading] Don't use DomTree for AA in JumpThreading (#79294)

JumpThreading may perform AA queries while the dominator tree is not up
to date, which may result in miscompilations.

Fix this by adding a new AAQI option to disable the use of the dominator
tree in BasicAA.

Fixes https://github.com/llvm/llvm-project/issues/79175.

show more ...


Revision tags: llvmorg-18.1.0-rc1
# 89dae798 24-Jan-2024 Nikita Popov <npopov@redhat.com>

[Loads] Use BatchAAResults for available value APIs (NFCI)

This allows caching AA queries both within and across the calls,
and enables us to use a custom AAQI configuration.


# 873a7bb1 24-Jan-2024 Kazu Hirata <kazu@google.com>

[Transforms] Use llvm::pred_size and llvm::predecessors (NFC)


12345678910>>...23