[BranchFolding] Remove getBranchDebugLoc() (#114613)

[CodeGen] Use MCRegister instead of MCPhysReg in RegisterMaskPair. NFC (#123688)

Update some other places to avoid implicit conversions this introduces,
but I probably missed some.

[aarch64][win] Update Called Globals info when updating Call Site info (#122762)

Fixes the "use after poison" issue introduced by #121516 (see
<https://github.com/llvm/llvm-project/pull/121516#issue

[aarch64][win] Update Called Globals info when updating Call Site info (#122762)

Fixes the "use after poison" issue introduced by #121516 (see
<https://github.com/llvm/llvm-project/pull/121516#issuecomment-2585912395>).

The root cause of this issue is that #121516 introduced "Called Global"
information for call instructions modeling how "Call Site" info is
stored in the machine function, HOWEVER it didn't copy the
copy/move/erase operations for call site information.

The fix is to rename and update the existing copy/move/erase functions
so they also take care of Called Global info.

show more ...

[NFC] Remove some unnecessary semicolons

All inside LLVM_DEBUG, some of which have been cleaned up by adding block
scopes to allow them to format more nicely.

Check hasOptSize() in shouldOptimizeForSize() (#112626)

[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.

[BranchFolding] Add a hook to override tail merge size (#99025)

A new hook `TargetInstrInfo::getTailMergeSize()` is added so that
targets can override it.

This removes an existing TODO.

[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 ...

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

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

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 ...

Revert "[CodeGen][NewPM] Port machine-branch-prob to new pass manager" (#96858)

Reverts llvm/llvm-project#96389
Some ppc bots failed.

[CodeGen][NewPM] Port machine-branch-prob to new pass manager (#96389)

Like IR version `print<branch-prob>`, there is also a
`print<machine-branch-prob>`.

[BranchFolder] Fix missing debug info with tail merging (#94715)

`BranchFolder::TryTailMergeBlocks(...)` removes unconditional branch
instructions and then recreates them. However, this process los

[BranchFolder] Fix missing debug info with tail merging (#94715)

`BranchFolder::TryTailMergeBlocks(...)` removes unconditional branch
instructions and then recreates them. However, this process loses debug
source location information from the previous branch instruction, even
if tail merging doesn't change IR. This patch preserves the debug
information from the removed instruction and inserts them into the
recreated instruction.

Fixes #94050

show more ...

[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 ...

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 ...

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

This reverts commit 59bf60519fc30d9d36c86abd83093b068f6b1e4b.

Introduces a major compile-time regression.

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 ...

[BranchFolding] Use isSuccessor to confirm fall through (#77923)

When merging blocks, if the previous block has no any branch instruction
and has one successor, the successor may be SEH landing pad

[BranchFolding] Use isSuccessor to confirm fall through (#77923)

When merging blocks, if the previous block has no any branch instruction
and has one successor, the successor may be SEH landing pad and the
block will always raise exception and nerver fall through to next block.
We can not merge them in such case. isSuccessor should be used to
confirm it can fall through to next block.

show more ...

[BranchFolding] Fix missing predecessors of landing-pad (#77608)

When removing an empty machine basic block, all of its successors should
be inherited by its fall through MBB. This keeps CFG as onl

[BranchFolding] Fix missing predecessors of landing-pad (#77608)

When removing an empty machine basic block, all of its successors should
be inherited by its fall through MBB. This keeps CFG as only have one
entry which is required by LiveDebugValues.

Reland #77441 as LiveDebugValues test.

show more ...

[BranchFolding] Remove dubious assert from operator< (#71639)

`MergePotentialElts::operator<` asserts that the two elements being
compared are not equal. However, sorting functions are allowed to i

[BranchFolding] Remove dubious assert from operator< (#71639)

`MergePotentialElts::operator<` asserts that the two elements being
compared are not equal. However, sorting functions are allowed to invoke
the comparison function with equal arguments (though they usually don't
for efficiency reasons).

There is an existing special-case that disables the assert if
_GLIBCXX_DEBUG is used, which may invoke the comparator with equal args
to verify strict weak ordering. I believe libc++ also has strict weak
ordering checks under some options nowadays.

Recently, #71312 was reported, where a change to glibc's qsort_r
implementation can also result in comparison between equal elements.
From what I understood, this is an inefficiency that will be fixed on
the glibc side as well, but I think at this point we should just remove
this assertion.

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

show more ...

[CodeGen] Make use of MachineInstr::all_defs and all_uses. NFCI.

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

[BranchFolder] Skip redundant IMPLICIT_DEFs of subregs

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

[MC] Use subregs/superregs instead of MCSubRegIterator/MCSuperRegIterator. NFC.

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

Reland "[Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 2"

This reverts commit db6a979ae82410e42430e47afa488936ba8e3025.

Reland D102817 without any change. The previous revert was a m

Reland "[Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 2"

This reverts commit db6a979ae82410e42430e47afa488936ba8e3025.

Reland D102817 without any change. The previous revert was a mistake.

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

show more ...

Recommit "Improve and enable folding of conditional branches with tail calls." (2nd Try)

Improve and enable folding of conditional branches with tail calls.

1. Make it so that conditional tail call

Recommit "Improve and enable folding of conditional branches with tail calls." (2nd Try)

Improve and enable folding of conditional branches with tail calls.

1. Make it so that conditional tail calls can be emitted even when
there are multiple predecessors.

2. Don't guard the transformation behind -Os. The rationale for
guarding it was static-prediction can be affected by whether the
branch is forward of backward. This is no longer true for almost any
X86 cpus (anything newer than `SnB`) so is no longer a meaningful
concern.

Reviewed By: pengfei

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

show more ...