History log of /llvm-project/llvm/lib/Target/ARM/ARMLowOverheadLoops.cpp (Results 1 – 25 of 148)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4
# 9571cc2b 13-Nov-2024 Kazu Hirata <kazu@google.com>

[ARM] Remove unused includes (NFC) (#115995)

Identified with misc-include-cleaner.


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1
# cee65092 23-Sep-2024 Kazu Hirata <kazu@google.com>

[ARM] Avoid repeated hash lookups (NFC) (#109602)


# d84411f6 22-Sep-2024 Kazu Hirata <kazu@google.com>

[ARM] clang-format ARMLowOverheadLoops.cpp (NFC)

I'm going to touch this area in a subsequent patch.


Revision tags: 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
# 79d0de2a 09-Jul-2024 paperchalice <liujunchang97@outlook.com>

[CodeGen][NewPM] Port `machine-loops` to new pass manager (#97793)

- Add `MachineLoopAnalysis`.
- Add `MachineLoopPrinterPass`.
- Convert to `MachineLoopInfoWrapperPass` in legacy pass manager.


# ddaa93b0 29-Jun-2024 Kazu Hirata <kazu@google.com>

[llvm] Use std::make_unique (NFC) (#97165)

This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr<Type>(new

[llvm] Use std::make_unique (NFC) (#97165)

This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr<Type>(new Type()), which is a bit mouthful.

show more ...


Revision tags: llvmorg-18.1.8
# 5fe73071 06-Jun-2024 David Green <david.green@arm.com>

[ARM] Don't block tail-predication from unrelated VPT blocks. (#94239)

VPT blocks that do not produce an interesting 'output' (like a stored
value or reduction result), do not need to be predicated

[ARM] Don't block tail-predication from unrelated VPT blocks. (#94239)

VPT blocks that do not produce an interesting 'output' (like a stored
value or reduction result), do not need to be predicated on vctp for the
whole loop to be tail-predicated. Just producing results for the valid
tail predication lanes should be enough.

show more ...


Revision tags: llvmorg-18.1.7
# 850f30c3 29-May-2024 David Green <david.green@arm.com>

[ARM][MVE] Don't allow tail-predication with else predicates

The test case contains a vpt block with an else predicated instruction. This
might not be very unrealistic, but currently crashes due to

[ARM][MVE] Don't allow tail-predication with else predicates

The test case contains a vpt block with an else predicated instruction. This
might not be very unrealistic, but currently crashes due to not being able to
handle the else. The instruction would need to be removed. This patch adds some
extra checks that none of the instructions in vpt block is else predicated,
leaving it using vctp.

show more ...


# af36fb00 28-May-2024 David Green <david.green@arm.com>

[ARM] Remove static variables from ARMLowOverheadLoops. NFC

VPTState was holding static state, and acting as both the info in a VPTBlock
and the overall state of all the blocks in the loop. This has

[ARM] Remove static variables from ARMLowOverheadLoops. NFC

VPTState was holding static state, and acting as both the info in a VPTBlock
and the overall state of all the blocks in the loop. This has been split up
into a class (VPTBlock) to hold the instructions of one block, and VPTState
that holds the overall state. The PredicatedInsts is also made into a
map<MachineInstr *, SetVector<MachineInstr *>>, as the double-storing of MI
inside a unique pointer is unneeded.

show more ...


Revision tags: llvmorg-18.1.6, llvmorg-18.1.5
# f6d431f2 24-Apr-2024 Xu Zhang <simonzgx@gmail.com>

[CodeGen] Make the parameter TRI required in some functions. (#85968)

Fixes #82659

There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many

[CodeGen] Make the parameter TRI required in some functions. (#85968)

Fixes #82659

There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI parameters, as shown in issue #82411.

Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`, `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact.

After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.

show more ...


Revision tags: llvmorg-18.1.4
# 21d17709 15-Apr-2024 Kai Nacke <kai.peter.nacke@ibm.com>

[NFC] Refactor looping over recomputeLiveIns into function (#88040)

https://github.com/llvm/llvm-project/pull/79940 put calls to
recomputeLiveIns into
a loop, to repeatedly call the function until

[NFC] Refactor looping over recomputeLiveIns into function (#88040)

https://github.com/llvm/llvm-project/pull/79940 put calls to
recomputeLiveIns into
a loop, to repeatedly call the function until the computation converges.
However,
this repeats a lot of code. This changes moves the loop into a function
to simplify
the handling.

Note that this changes the order in which recomputeLiveIns is called.
For example,

```
bool anyChange = false;
do {
anyChange = recomputeLiveIns(*ExitMBB) || recomputeLiveIns(*LoopMBB);
} while (anyChange);
```

only begins to recompute the live-ins for LoopMBB after the computation
for ExitMBB
has converged. With this change, all basic blocks have a recomputation
of the live-ins
for each loop iteration. This can result in less or more calls,
depending on the
situation.

show more ...


Revision tags: 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
# ff4636a4 31-Jan-2024 Oskar Wirga <10386631+oskarwirga@users.noreply.github.com>

Refactor recomputeLiveIns to converge on added MachineBasicBlocks (#79940)

This is a fix for the regression seen in
https://github.com/llvm/llvm-project/pull/79498

> Currently, the way that reco

Refactor recomputeLiveIns to converge on added MachineBasicBlocks (#79940)

This is a fix for the regression seen in
https://github.com/llvm/llvm-project/pull/79498

> Currently, the way that recomputeLiveIns works is that it will
recompute the livein registers for that MachineBasicBlock but it matters
what order you call recomputeLiveIn which can result in incorrect
register allocations down the line.

Now we do not recompute the entire CFG but we do ensure that the newly
added MBB do reach convergence.

show more ...


Revision tags: llvmorg-18.1.0-rc1
# 07a1925b 26-Jan-2024 Nikita Popov <nikita.ppv@gmail.com>

Revert "Refactor recomputeLiveIns to operate on whole CFG (#79498)"

This reverts commit 59bf60519fc30d9d36c86abd83093b068f6b1e4b.

Introduces a major compile-time regression.


# 59bf6051 26-Jan-2024 Oskar Wirga <10386631+oskarwirga@users.noreply.github.com>

Refactor recomputeLiveIns to operate on whole CFG (#79498)

Currently, the way that recomputeLiveIns works is that it will recompute
the livein registers for that MachineBasicBlock but it matters wh

Refactor recomputeLiveIns to operate on whole CFG (#79498)

Currently, the way that recomputeLiveIns works is that it will recompute
the livein registers for that MachineBasicBlock but it matters what
order you call recomputeLiveIn which can result in incorrect register
allocations down the line.

This PR fixes that by simply recomputing the liveins for the entire CFG
until convergence is achieved. This makes it harder to introduce subtle
bugs which alter liveness.

show more ...


Revision tags: llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5
# 01702c3f 11-Nov-2023 Kazu Hirata <kazu@google.com>

[llvm] Stop including llvm/ADT/SmallSet.h (NFC)

Identified with clangd.


Revision tags: 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
# c64d0a7f 17-May-2023 Kazu Hirata <kazu@google.com>

[ARM] Remove unused declaration isSafeToDefineLR

The corresponding function definition was removed by:

commit e82a0084d322948b94a5ca3213237d5eeab4920f
Author: Sam Parker <sam.parker@arm.com>

[ARM] Remove unused declaration isSafeToDefineLR

The corresponding function definition was removed by:

commit e82a0084d322948b94a5ca3213237d5eeab4920f
Author: Sam Parker <sam.parker@arm.com>
Date: Fri Sep 25 09:36:40 2020 +0100

show more ...


Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0
# a0a76804 15-Mar-2023 Jakub Kuderski <kubak@google.com>

[ADT] Allow `llvm::enumerate` to enumerate over multiple ranges

This does not work by a mere composition of `enumerate` and `zip_equal`,
because C++17 does not allow for recursive expansion of struc

[ADT] Allow `llvm::enumerate` to enumerate over multiple ranges

This does not work by a mere composition of `enumerate` and `zip_equal`,
because C++17 does not allow for recursive expansion of structured
bindings.

This implementation uses `zippy` to manage the iteratees and adds the
stream of indices as the first zipped range. Because we have an upfront
assertion that all input ranges are of the same length, we only need to
check if the second range has ended during iteration.

As a consequence of using `zippy`, `enumerate` will now follow the
reference and lifetime semantics of the `zip*` family of functions. The
main difference is that `enumerate` exposes each tuple of references
through a new tuple-like type `enumerate_result`, with the familiar
`.index()` and `.value()` member functions.

Because the `enumerate_result` returned on dereference is a
temporary, enumeration result can no longer be used through an
lvalue ref.

Reviewed By: dblaikie, zero9178

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

show more ...


Revision tags: llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2
# a07584d5 03-Feb-2023 Jay Foad <jay.foad@amd.com>

[CodeGen] Make more use of MachineOperand::getOperandNo. NFC.

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


Revision tags: llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# e828dd43 11-Jan-2023 David Green <david.green@arm.com>

[ARM] Don't treat arguments as producesFalseLanesZero

Invalid tail predicated loops could be formed by treating function
arguments as FalseLanesZero due to getGlobalReachingDefs not returning
any va

[ARM] Don't treat arguments as producesFalseLanesZero

Invalid tail predicated loops could be formed by treating function
arguments as FalseLanesZero due to getGlobalReachingDefs not returning
any values. Make sure we check that the list of Defs is empty and if so
treat it like a unknown value.

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

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2
# 4c4e544c 29-Sep-2022 David Green <david.green@arm.com>

[ARM] Add an option for disabling omitting DLS.

Useful for testing, this option disables when `DLS lr, lr` gets removed.


Revision tags: llvmorg-15.0.1, llvmorg-15.0.0
# 2833760c 29-Aug-2022 Kazu Hirata <kazu@google.com>

[Target] Qualify auto in 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, llvmorg-14.0.6, llvmorg-14.0.5
# ad73ce31 26-May-2022 Zongwei Lan <lanzongwei541@gmail.com>

[Target] use getSubtarget<> instead of static_cast<>(getSubtarget())

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


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 989f1c72 15-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# ed98c1b3 09-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332


# a278250b 10-Mar-2022 Nico Weber <thakis@chromium.org>

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...


# 7f230fee 07-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup codegen includes

after: 1061034926
before: 1063332844

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


123456