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

Identified with misc-include-cleaner.

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

[ARM] Fix formatting (NFC)

I'm about to post a PR in this area.

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

[Target] Use llvm::replace (NFC) (#105942)

Rapply "[Target] Use range-based for loops (NFC) (#98844)"

This iteration drops hunks where the loop body adds more elements.

Revert "[Target] Use range-based for loops (NFC) (#98844)"

This reverts commit 3614f65a7ba9d925010e3316a1d93bcebc632178.

fixupImmediateBr seems to resize ImmBranches.

[Target] Use range-based for loops (NFC) (#98844)

[CodeGen][NewPM] Split `MachineDominatorTree` into a concrete analysis result (#94571)

Prepare for new pass manager version of `MachineDominatorTreeAnalysis`.
We may need a machine dominator tree v

[CodeGen][NewPM] Split `MachineDominatorTree` into a concrete analysis result (#94571)

Prepare for new pass manager version of `MachineDominatorTreeAnalysis`.
We may need a machine dominator tree version of `DomTreeUpdater` to
handle `SplitCriticalEdge` in some CodeGen passes.

show more ...

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

Reapply "Convert many LivePhysRegs uses to LiveRegUnits" (#84338)

This only converts the instances where all that is needed is to change
the variable type name.

Basically, anything that involves

Reapply "Convert many LivePhysRegs uses to LiveRegUnits" (#84338)

This only converts the instances where all that is needed is to change
the variable type name.

Basically, anything that involves a function that LiveRegUnits does not
directly have was skipped to play it safe.

Reverts
https://github.com/llvm/llvm-project/commit/7a0e222a17058a311b69153d0b6f1b4459414778

show more ...

Revert "Convert many LivePhysRegs uses to LiveRegUnits (#83905)"

This reverts commit 2a13422b8bcee449405e3ebff957b4020805f91c.

It was causing test failures on the expensive check builders.

Convert many LivePhysRegs uses to LiveRegUnits (#83905)

[ARM] Update IsRestored for LR based on all returns (#82745)

PR #75527 fixed ARMFrameLowering to set the IsRestored flag for LR based
on all of the return instructions in the function, not just one

[ARM] Update IsRestored for LR based on all returns (#82745)

PR #75527 fixed ARMFrameLowering to set the IsRestored flag for LR based
on all of the return instructions in the function, not just one.
However, there is also code in ARMLoadStoreOptimizer which changes
return instructions, but it set IsRestored based on the one instruction
it changed, not the whole function.

The fix is to factor out the code added in #75527, and also call it from
ARMLoadStoreOptimizer if it made a change to return instructions.

Fixes #80287.

show more ...

[Target] Use range-based for loops (NFC)

[llvm] Use llvm::erase_if (NFC)

[ARM] Adjust strd/ldrd codegen alignment requirements

In change https://reviews.llvm.org/D152790, it was discovered that the
alignment requirement calculation for LDRD/STRD codegen was suboptimal
an

[ARM] Adjust strd/ldrd codegen alignment requirements

In change https://reviews.llvm.org/D152790, it was discovered that the
alignment requirement calculation for LDRD/STRD codegen was suboptimal
and the calculation for volatile loads and stores was adjusted.

This change here adopts the calculation for the remaining non-volatile
occurances.

Recommitting after undefined behavior fix in D155093.

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

show more ...

Revert "[ARM] Adjust strd/ldrd codegen alignment requirements"

This reverts commit 92a9c30c61da7f973d55cd84fade424159b9cac9.

This has caused a test failure in the 2nd stage of Linaro's
Arm 32 bit b

Revert "[ARM] Adjust strd/ldrd codegen alignment requirements"

This reverts commit 92a9c30c61da7f973d55cd84fade424159b9cac9.

This has caused a test failure in the 2nd stage of Linaro's
Arm 32 bit buildbots.

LLVM::simplified-template-names.s

7: error: Simplified template DW_AT_name could not be reconstituted:
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8: original: f3<unsigned char, (unsigned char)'\x00'>
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9: reconstituted: f3<unsigned char, (unsigned char)'\x7f'>
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I suspect a load/store is slightly off.

show more ...

[ARM] Adjust strd/ldrd codegen alignment requirements

In change https://reviews.llvm.org/D152790, it was discovered that the
alignment requirement calculation for LDRD/STRD codegen was suboptimal
an

[ARM] Adjust strd/ldrd codegen alignment requirements

In change https://reviews.llvm.org/D152790, it was discovered that the
alignment requirement calculation for LDRD/STRD codegen was suboptimal
and the calculation for volatile loads and stores was adjusted.

This change here adopts the calculation for the remaining non-volatile
occurances.

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

show more ...

Fix a warning in D149762 [-Wunused-variable]

Change if() continue; to an assert if a DBG_VALUE or DBG_VALUE_LIST returns a null DILocalVariable

A DBG_VALUE or DBG_VALUE_LIST must always return a non-null
DILocalVariable, the ARMLoadStoreOptim

Change if() continue; to an assert if a DBG_VALUE or DBG_VALUE_LIST returns a null DILocalVariable

A DBG_VALUE or DBG_VALUE_LIST must always return a non-null
DILocalVariable, the ARMLoadStoreOptimizer code that move’s DBG_VALUE
and DBG_VALUE_LIST instructions if their corresponding loads have been
moved, currently just continues if it finds a DBG_VALUE or
DBG_VALUE_LIST with a null DILocalVariable, change that to an assert.

Differential revision: https://reviews.llvm.org/D149762

show more ...

Move DBG_VALUE's that depend on loads to after a
load if the load is moved due to the pre register allocation ld/st
optimization pass

The issue here is that there can be a scenario where debug infor

Move DBG_VALUE's that depend on loads to after a
load if the load is moved due to the pre register allocation ld/st
optimization pass

The issue here is that there can be a scenario where debug information
is lost because of the pre register allocation load store optimization
pass, where a load who's result describes the debug infomation for a
local variable gets moved below the load and that causes the debug
information for that load to get lost.

Example:

Before the Pre Register Allocation Load Store Pass
inst_a
%2 = ld ...
inst_b
DBG_VALUE %2, "x", ...
%3 = ld ...

After the Pass:
inst_a
inst_b
DBG_VALUE %2, "x", ...
%2 = ld ...
%3 = ld ...

The load has now been moved to after the DBG_VAL that uses its result
and the debug info for "x" has been lost. What we want is:

inst_a
inst_b
%2 = ld ...
DBG_VALUE %2, "x", ...
%3 = ld ...

Which is what this patch addresses

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

show more ...

Revert "Move DBG_VALUE's that depend on loads to after a"

This reverts commit 0aaf634152f25a805563d552e72d89e8202d84f2.

Reverted this because of build failure https://lab.llvm.org/buildbot#builders

Revert "Move DBG_VALUE's that depend on loads to after a"

This reverts commit 0aaf634152f25a805563d552e72d89e8202d84f2.

Reverted this because of build failure https://lab.llvm.org/buildbot#builders/245/builds/7035

/home/tcwg-buildbot/worker/clang-armv8-quick/llvm/llvm/test/DebugInfo/Generic/incorrect-variable-debugloc1.ll:28:12: error: DWARF23: expected string not found in input
; DWARF23: DW_OP_lit13{{$}}
^
<stdin>:1:1: note: scanning from here
-: file format elf32-littlearm
^
<stdin>:19:20: note: possible intended match here
DW_AT_frame_base (DW_OP_reg13 SP)
^

show more ...

Move DBG_VALUE's that depend on loads to after a
load if the load is moved due to the pre register allocation ld/st
optimization pass

The issue here is that there can be a scenario where debug infor

Move DBG_VALUE's that depend on loads to after a
load if the load is moved due to the pre register allocation ld/st
optimization pass

The issue here is that there can be a scenario where debug information
is lost because of the pre register allocation load store optimization
pass, where a load who's result describes the debug infomation for a
local variable gets moved below the load and that causes the debug
information for that load to get lost.

Example:

Before the Pre Register Allocation Load Store Pass
inst_a
%2 = ld ...
inst_b
DBG_VALUE %2, "x", ...
%3 = ld ...

After the Pass:
inst_a
inst_b
DBG_VALUE %2, "x", ...
%2 = ld ...
%3 = ld ...

The load has now been moved to after the DBG_VAL that uses its result
and the debug info for "x" has been lost. What we want is:

inst_a
inst_b
%2 = ld ...
DBG_VALUE %2, "x", ...
%3 = ld ...

Which is what this patch addresses

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

show more ...

[ARM] Allow distributing postinc with PHI uses

Although this doesn't usually come up, we can have uses of the
BaseAccess of a distributed postinc being a PHI. This doesn't need the
usual dominance c

[ARM] Allow distributing postinc with PHI uses

Although this doesn't usually come up, we can have uses of the
BaseAccess of a distributed postinc being a PHI. This doesn't need the
usual dominance check as we will dominate along the phi edge, allowing
us to still create a postinc load/store.

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

show more ...