Revision tags: llvmorg-21-init |
|
#
9fecb4f9 |
| 24-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Fix a warning
This patch fixes:
llvm/lib/CodeGen/MachineSink.cpp:1667:22: error: unused variable 'Preheader' [-Werror,-Wunused-variable]
|
#
acb7859f |
| 24-Jan-2025 |
Jeffrey Byrnes <jeffrey.byrnes@amd.com> |
[MachineSink] Extend loop sinking capability (#117247)
The current MIR cycle sinking capabilities are rather limited. It only
support sinking copies into a single successor block while obeying
lim
[MachineSink] Extend loop sinking capability (#117247)
The current MIR cycle sinking capabilities are rather limited. It only
support sinking copies into a single successor block while obeying
limits.
This opt-in feature adds a more aggressive option, that is not limited
to the above concerns. The feature will try to "sink" by duplicating any
top-level preheader instruction (that we are sure is safe to sink) into
any user block, then does some dead code cleanup. In particular, this is
useful for high RP situations when loop bodies have control flow.
show more ...
|
#
fa9fb2ae |
| 18-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Avoid repeated hash lookups (NFC) (#123447)
|
Revision tags: llvmorg-19.1.7 |
|
#
b6ad2316 |
| 18-Dec-2024 |
Pengcheng Wang <wangpengcheng.pp@bytedance.com> |
[MachineSink] Use `RegisterClassInfo::getRegPressureSetLimit` (#119830)
`RegisterClassInfo::getRegPressureSetLimit` is a wrapper of `TargetRegisterInfo::getRegPressureSetLimit` with some logics to a
[MachineSink] Use `RegisterClassInfo::getRegPressureSetLimit` (#119830)
`RegisterClassInfo::getRegPressureSetLimit` is a wrapper of `TargetRegisterInfo::getRegPressureSetLimit` with some logics to adjust the limit by removing reserved registers.
It seems that we shouldn't use `TargetRegisterInfo::getRegPressureSetLimit` directly, just like the comment "This limit must be adjusted dynamically for reserved registers" said.
Separate from https://github.com/llvm/llvm-project/pull/118787
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
1562b70e |
| 13-Dec-2024 |
paperchalice <liujunchang97@outlook.com> |
Reapply "[DomTreeUpdater] Move critical edge splitting code to updater" (#119547)
This relands commit #115111.
Use traditional way to update post dominator tree, i.e. break critical
edge splitting
Reapply "[DomTreeUpdater] Move critical edge splitting code to updater" (#119547)
This relands commit #115111.
Use traditional way to update post dominator tree, i.e. break critical
edge splitting into insert, insert, delete sequence.
When splitting critical edges, the post dominator tree may change its
root node, and `setNewRoot` only works in normal dominator tree...
See
https://github.com/llvm/llvm-project/blob/6c7e5827eda26990e872eb7c3f0d7866ee3c3171/llvm/include/llvm/Support/GenericDomTree.h#L684-L687
show more ...
|
#
553058f8 |
| 11-Dec-2024 |
paperchalice <liujunchang97@outlook.com> |
Revert "[DomTreeUpdater] Move critical edge splitting code to updater" (#119512)
Reverts llvm/llvm-project#115111 Causes #119511
|
#
79047fac |
| 11-Dec-2024 |
paperchalice <liujunchang97@outlook.com> |
[DomTreeUpdater] Move critical edge splitting code to updater (#115111)
Support critical edge splitting in dominator tree updater. Continue the
work in #100856.
Compile time check:
https://llvm
[DomTreeUpdater] Move critical edge splitting code to updater (#115111)
Support critical edge splitting in dominator tree updater. Continue the
work in #100856.
Compile time check:
https://llvm-compile-time-tracker.com/compare.php?from=87c35d782795b54911b3e3a91a5b738d4d870e55&to=42b3e5623a9ab4c3648564dc0926b36f3b438a3a&stat=instructions%3Au
show more ...
|
Revision tags: llvmorg-19.1.5 |
|
#
6657d4bd |
| 26-Nov-2024 |
Philip Reames <preames@rivosinc.com> |
[TTI][RISCV] Unconditionally break critical edges to sink ADDI (#108889)
This looks like a rather weird change, so let me explain why this isn't
as unreasonable as it looks. Let's start with the pr
[TTI][RISCV] Unconditionally break critical edges to sink ADDI (#108889)
This looks like a rather weird change, so let me explain why this isn't
as unreasonable as it looks. Let's start with the problem it's solving.
```
define signext i32 @overlap_live_ranges(ptr %arg, i32 signext %arg1) { bb:
%i = icmp eq i32 %arg1, 1
br i1 %i, label %bb2, label %bb5
bb2: ; preds = %bb
%i3 = getelementptr inbounds nuw i8, ptr %arg, i64 4
%i4 = load i32, ptr %i3, align 4
br label %bb5
bb5: ; preds = %bb2, %bb
%i6 = phi i32 [ %i4, %bb2 ], [ 13, %bb ]
ret i32 %i6
}
```
Right now, we codegen this as:
```
li a3, 1
li a2, 13
bne a1, a3, .LBB0_2
lw a2, 4(a0)
.LBB0_2:
mv a0, a2
ret
```
In this example, we have two values which must be assigned to a0 per the
ABI (%arg, and the return value). SelectionDAG ensures that all values
used in a successor phi are defined before exit the predecessor block.
This creates an ADDI to materialize the immediate in the entry block.
Currently, this ADDI is not sunk into the tail block because we'd have
to split a critical edges to do so. Note that if our immediate was
anything large enough to require two instructions we *would* split this
critical edge.
Looking at other targets, we notice that they don't seem to have this
problem. They perform the sinking, and tail duplication that we don't.
Why? Well, it turns out for AArch64 that this is entirely an accident of
the existance of the gpr32all register class. The immediate is
materialized into the gpr32 class, and then copied into the gpr32all
register class. The existance of that copy puts us right back into the
two instruction case noted above.
This change essentially just bypasses this emergent behavior aspect of
the aarch64 behavior, and implements the same "always sink immediates"
behavior for RISCV as well.
show more ...
|
#
e72209db |
| 20-Nov-2024 |
Ellis Hoag <ellis.sparky.hoag@gmail.com> |
[MachineSink] Fix stable sort comparator (#116705)
Fix the comparator in `stable_sort()` to satisfy the strict weak
ordering requirement.
In https://github.com/llvm/llvm-project/pull/115367 this
[MachineSink] Fix stable sort comparator (#116705)
Fix the comparator in `stable_sort()` to satisfy the strict weak
ordering requirement.
In https://github.com/llvm/llvm-project/pull/115367 this comparator was
changed to use `getCycleDepth()` when `shouldOptimizeForSize()` is true.
However, I mistakenly changed to logic so that we use `LHSFreq <
RHSFreq` if **either** of them are zero. This causes us to fail the last
requirment (https://en.cppreference.com/w/cpp/named_req/Compare).
> if comp(a, b) == true and comp(b, c) == true then comp(a, c) == true
show more ...
|
Revision tags: llvmorg-19.1.4 |
|
#
43bef75f |
| 14-Nov-2024 |
Akshat Oke <Akshat.Oke@amd.com> |
[NFC][CodeGen] Clang format MachineSink.cpp (#114027)
Preparing to port this pass to new pass manager.
|
#
735ab61a |
| 13-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Remove unused includes (NFC) (#115996)
Identified with misc-include-cleaner.
|
#
57c33aca |
| 12-Nov-2024 |
Ellis Hoag <ellis.sparky.hoag@gmail.com> |
[MachineSink] Sink into consistent blocks for optsize funcs (#115367)
Do not consider profile data when choosing a successor block to sink
into for optsize functions. This should result in more con
[MachineSink] Sink into consistent blocks for optsize funcs (#115367)
Do not consider profile data when choosing a successor block to sink
into for optsize functions. This should result in more consistent
instruction sequences which will improve outlining and ICF. We've
observed a slight codesize improvement in a large binary. This is
similar reasoning to https://github.com/llvm/llvm-project/pull/114607.
Using profile data to select a block to sink into was original added in
https://github.com/llvm/llvm-project/commit/d04f7596e79d7c5cf7e4249ad62690afaecd01ec.
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
e33e087a |
| 25-Sep-2024 |
Ruiling, Song <ruiling.song@amd.com> |
[MachineSink] Update register dependency correctly (#109763)
The accumulateUsedDefed() was missing if block prologue interference
check does not pass. This would cause incorrect register dependency
[MachineSink] Update register dependency correctly (#109763)
The accumulateUsedDefed() was missing if block prologue interference
check does not pass. This would cause incorrect register dependency,
which cause incorrect sinking.
show more ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
3d08ade7 |
| 29-Aug-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[ExtendLifetimes] Implement llvm.fake.use to extend variable lifetimes (#86149)
This patch is part of a set of patches that add an `-fextend-lifetimes`
flag to clang, which extends the lifetimes of
[ExtendLifetimes] Implement llvm.fake.use to extend variable lifetimes (#86149)
This patch is part of a set of patches that add an `-fextend-lifetimes`
flag to clang, which extends the lifetimes of local variables and
parameters for improved debuggability. In addition to that flag, the
patch series adds a pragma to selectively disable `-fextend-lifetimes`,
and an `-fextend-this-ptr` flag which functions as `-fextend-lifetimes`
for this pointers only. All changes and tests in these patches were
written by Wolfgang Pieb (@wolfy1961), while Stephen Tozer (@SLTozer)
has handled review and merging. The extend lifetimes flag is intended to
eventually be set on by `-Og`, as discussed in the RFC
here:
https://discourse.llvm.org/t/rfc-redefine-og-o1-and-add-a-new-level-of-og/72850
This patch implements a new intrinsic instruction in LLVM,
`llvm.fake.use` in IR and `FAKE_USE` in MIR, that takes a single operand
and has no effect other than "using" its operand, to ensure that its
operand remains live until after the fake use. This patch does not emit
fake uses anywhere; the next patch in this sequence causes them to be
emitted from the clang frontend, such that for each variable (or this) a
fake.use operand is inserted at the end of that variable's scope, using
that variable's value. This patch covers everything post-frontend, which
is largely just the basic plumbing for a new intrinsic/instruction,
along with a few steps to preserve the fake uses through optimizations
(such as moving them ahead of a tail call or translating them through
SROA).
Co-authored-by: Stephen Tozer <stephen.tozer@sony.com>
show more ...
|
#
83fc989a |
| 22-Aug-2024 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Construct SmallVector with iterator ranges (NFC) (#105622)
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1 |
|
#
ed4e75d5 |
| 26-Jul-2024 |
Pengcheng Wang <wangpengcheng.pp@bytedance.com> |
[CodeGen] Remove AA parameter of isSafeToMove (#100691)
This `AA` parameter is not used and for most uses they just pass a nullptr.
The use of `AA` was removed since 8d0383e.
|
Revision tags: llvmorg-20-init |
|
#
495d3ea9 |
| 17-Jul-2024 |
Craig Topper <craig.topper@sifive.com> |
[MachineSink][RISCV] Only call isConstantPhysReg or isIgnorableUse for uses. (#99363)
The included test case contains X0 as a def register. X0 is considered a
constant register when it is a use. Wh
[MachineSink][RISCV] Only call isConstantPhysReg or isIgnorableUse for uses. (#99363)
The included test case contains X0 as a def register. X0 is considered a
constant register when it is a use. When its a def, it means to throw
away the result value.
If we treat it as a constant register here, we will execute the continue
and not assign `DefReg` to any register. This will cause a crash when
trying to get the register class for `DefReg` after the loop.
By only checking isConstantPhysReg for uses, we will reach the `return
false` a little further down and stop processing this instruction.
show more ...
|
#
7b135f7c |
| 12-Jul-2024 |
yozhu <101743168+yozhu@users.noreply.github.com> |
[MachineSink] Check predecessor/successor relationship between two basic blocks involved in critical edge splitting (#98540)
Fix an issue in #97618 - if the two basic blocks involved are not
predec
[MachineSink] Check predecessor/successor relationship between two basic blocks involved in critical edge splitting (#98540)
Fix an issue in #97618 - if the two basic blocks involved are not
predecessor / successor to each other, treat the candidate as illegal
for critical edge splitting.
Closes #98477 (checked in test copied from its comment).
show more ...
|
#
09989996 |
| 12-Jul-2024 |
paperchalice <liujunchang97@outlook.com> |
[CodeGen][NewPM] Port `machine-block-freq` to new pass manager (#98317)
- Add `MachineBlockFrequencyAnalysis`.
- Add `MachineBlockFrequencyPrinterPass`.
- Use `MachineBlockFrequencyInfoWrapperPass
[CodeGen][NewPM] Port `machine-block-freq` to new pass manager (#98317)
- Add `MachineBlockFrequencyAnalysis`.
- Add `MachineBlockFrequencyPrinterPass`.
- Use `MachineBlockFrequencyInfoWrapperPass` in legacy pass manager.
- `LazyMachineBlockFrequencyInfo::print` is empty, drop it due to new
pass manager migration.
show more ...
|
#
04c8c95c |
| 11-Jul-2024 |
YongKang Zhu <yongzhu@fb.com> |
Revert "[MachineSink] Only add sink candidate if ToBB is a successor of fromBB"
This reverts commit 546c09018a615388a36bdf898649fffbd2df529f.
|
#
546c0901 |
| 11-Jul-2024 |
YongKang Zhu <yongzhu@fb.com> |
[MachineSink] Only add sink candidate if ToBB is a successor of fromBB
|
#
7e2f9619 |
| 09-Jul-2024 |
Min-Yih Hsu <min.hsu@sifive.com> |
[MachineSink] Fix missing sinks along critical edges (#97618)
4e0bd3f improved early MachineLICM's capabilities to hoist COPY from
physical registers out of a loop. However, it accidentally broke o
[MachineSink] Fix missing sinks along critical edges (#97618)
4e0bd3f improved early MachineLICM's capabilities to hoist COPY from
physical registers out of a loop. However, it accidentally broke one of
MachineSink's preconditions on sinking cheap instructions (in this case,
COPY) which considered those instructions being profitable to sink only
when there are at least two of them in the same def-use chain in the
same basic block. So if early MachineLICM hoisted one of them out,
MachineSink no longer sink rest of the cheap instructions. This results
in redundant load immediate instructions from the motivating example
we've seen on RISC-V.
This patch fixes this by teaching MachineSink that if there is more than
one demand to sink a register into the same block from different
critical edges, it should be considered profitable as it increases the
CSE opportunities.
This change also improves two of the AArch64's cases.
show more ...
|
#
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.
|
#
d38b518e |
| 28-Jun-2024 |
paperchalice <liujunchang97@outlook.com> |
Reapply "[CodeGen][NewPM] Port machine-branch-prob to new pass manager" (#96858) (#96869)
This reverts commit ab58b6d58edf6a7c8881044fc716ca435d7a0156.
In `CodeGen/Generic/MachineBranchProb.ll`, `l
Reapply "[CodeGen][NewPM] Port machine-branch-prob to new pass manager" (#96858) (#96869)
This reverts commit ab58b6d58edf6a7c8881044fc716ca435d7a0156.
In `CodeGen/Generic/MachineBranchProb.ll`, `llc` crashed with dumped MIR
when targeting PowerPC. Move test to `llc/new-pm`, which is X86
specific.
show more ...
|
#
ab58b6d5 |
| 27-Jun-2024 |
paperchalice <liujunchang97@outlook.com> |
Revert "[CodeGen][NewPM] Port machine-branch-prob to new pass manager" (#96858)
Reverts llvm/llvm-project#96389
Some ppc bots failed.
|