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


1234567891011