History log of /llvm-project/llvm/lib/Target/ARM/ARMFrameLowering.cpp (Results 1 – 25 of 311)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 9d9c5619 21-Jan-2025 Craig Topper <craig.topper@sifive.com>

[ARM] Use MCRegister instead of unsigned. NFC

Primarily around uses of getSubReg/getSuperReg.


Revision tags: llvmorg-19.1.7
# 1a935d7a 14-Jan-2025 Guy David <49722543+guy-david@users.noreply.github.com>

[llvm] Mark scavenging spill-slots as *spilled* stack objects. (#122673)

This seems like an oversight when copying code from other backends.


Revision tags: llvmorg-19.1.6, llvmorg-19.1.5
# 0611a668 19-Nov-2024 Kazu Hirata <kazu@google.com>

[ARM] Fix a warning

This patch fixes:

llvm/lib/Target/ARM/ARMFrameLowering.cpp:1404:39: error: unused
variable 'PushPopSplit' [-Werror,-Wunused-variable]


Revision tags: llvmorg-19.1.4
# d37554b6 17-Nov-2024 Benson Chu <bensonchu457@gmail.com>

[ARM] Specifically delineate between different GPRCS2 positions

Currently, the relative position of GPRCS2 (with respect to other
instructions in the prologue of a function) can be different dependi

[ARM] Specifically delineate between different GPRCS2 positions

Currently, the relative position of GPRCS2 (with respect to other
instructions in the prologue of a function) can be different depending
on the type of ARMSubtarget::PushPopSplitVariant.

When the PushPopSpiltVariant is SplitR11WindowsSEH, GPRCS2 comes
after both GPRCS1 and DPRCS2:

GPRCS1
DPRCS1
GPRCS2

However, in all other cases, GPRCS2 comes before DPRCS1, like so:

GPRCS1
GPRCS2
DPRCS1

This makes the MI walking code in ARMFrameLowering::emitPrologue a bit
confusing. If GPRCS2Size is non-zero, we also have to check the
PushPopSplitVariant to know if we will encounter the DPRCS1 push
instruction first or the GPRCS2 push instruction first.

This commit changes to SplitR11WindowsSEH such that the spill area is
as follows:

GPRCS1
DPRCS1
GPRCS3

This disambiguates a lot of the ARMFrameLowering.cpp MI traversal
code.

show more ...


# 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
# dff114b3 28-Oct-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] Optimise non-ABI frame pointers (#110286)

With -fomit-frame-pointer, even if we set up a frame pointer for other
reasons (e.g. variable-sized or over-aligned stack allocations), we
don't nee

[ARM] Optimise non-ABI frame pointers (#110286)

With -fomit-frame-pointer, even if we set up a frame pointer for other
reasons (e.g. variable-sized or over-aligned stack allocations), we
don't need to create an ABI-compliant frame record. This means that we
can save all of the general-purpose registers in one push, instead of
splitting it to ensure that the frame pointer and link register are
adjacent on the stack, saving two instructions per function.

show more ...


# 493529fb 17-Oct-2024 Oliver Stannard <oliver.stannard@arm.com>

Re-land: [ARM] Fix frame chains with M-profile PACBTI (#110285)

When using AAPCS-compliant frame chains with PACBTI return address
signing, there ware a number of bugs in the generation of the frame

Re-land: [ARM] Fix frame chains with M-profile PACBTI (#110285)

When using AAPCS-compliant frame chains with PACBTI return address
signing, there ware a number of bugs in the generation of the frame
pointer and function prologues. The most obvious was that we sometimes
would modify r11 before pushing it to the stack, so it wasn't preserved
as required by the PCS. We also sometimes did not push R11 and LR
adjacent to one another on the stack, or used R11 as a frame pointer
without pointing it at the saved value of R11, both of which are
required to have an AAPCS compliant frame chain.

The original work of this patch was done by James Westwood, reviewed as
#82801 and #81249, with some tidy-ups done by Mark Murray and myself.

show more ...


# 18ac0178 18-Oct-2024 Oliver Stannard <oliver.stannard@arm.com>

Revert "[ARM] Fix frame chains with M-profile PACBTI (#110285)"

Reverting because this is causing failures with MSan:
https://lab.llvm.org/buildbot/#/builders/169/builds/4378

This reverts commit e1

Revert "[ARM] Fix frame chains with M-profile PACBTI (#110285)"

Reverting because this is causing failures with MSan:
https://lab.llvm.org/buildbot/#/builders/169/builds/4378

This reverts commit e1f8f84acec05997893c305c78fbf7feecf44dd7.

show more ...


# ad4a582f 18-Oct-2024 Alex Rønne Petersen <alex@alexrp.com>

[llvm] Consistently respect `naked` fn attribute in `TargetFrameLowering::hasFP()` (#106014)

Some targets (e.g. PPC and Hexagon) already did this. I think it's best
to do this consistently so that

[llvm] Consistently respect `naked` fn attribute in `TargetFrameLowering::hasFP()` (#106014)

Some targets (e.g. PPC and Hexagon) already did this. I think it's best
to do this consistently so that frontend authors don't run into
inconsistent results when they emit `naked` functions. For example, in
Zig, we had to change our emit code to also set `frame-pointer=none` to
get reliable results across targets.

Note: I don't have commit access.

show more ...


# 4a2bd78f 17-Oct-2024 gxlayer <151722229+guoxin049@users.noreply.github.com>

[ARM] Fix -mno-omit-leaf-frame-pointer flag doesn't works on 32-bit ARM (#109628)

The -mno-omit-leaf-frame-pointer flag works on 32-bit ARM architectures
and addresses the bug reported in #108019


# 584e00a3 17-Oct-2024 Jie Fu <jiefu@tencent.com>

[ARM] Fix -Wunused-variable in ARMFrameLowering.cpp (NFC)

/llvm-project/llvm/lib/Target/ARM/ARMFrameLowering.cpp:1028:9:
error: unused variable 'FPOffset' [-Werror,-Wunused-variable]
int FPOffse

[ARM] Fix -Wunused-variable in ARMFrameLowering.cpp (NFC)

/llvm-project/llvm/lib/Target/ARM/ARMFrameLowering.cpp:1028:9:
error: unused variable 'FPOffset' [-Werror,-Wunused-variable]
int FPOffset = MFI.getObjectOffset(FramePtrSpillFI);
^
1 error generated.

show more ...


# e1f8f84a 17-Oct-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] Fix frame chains with M-profile PACBTI (#110285)

When using AAPCS-compliant frame chains with PACBTI return address
signing, there ware a number of bugs in the generation of the frame
pointe

[ARM] Fix frame chains with M-profile PACBTI (#110285)

When using AAPCS-compliant frame chains with PACBTI return address
signing, there ware a number of bugs in the generation of the frame
pointer and function prologues. The most obvious was that we sometimes
would modify r11 before pushing it to the stack, so it wasn't preserved
as required by the PCS. We also sometimes did not push R11 and LR
adjacent to one another on the stack, or used R11 as a frame pointer
without pointing it at the saved value of R11, both of which are
required to have an AAPCS compliant frame chain.

The original work of this patch was done by James Westwood, reviewed as
#82801 and #81249, with some tidy-ups done by Mark Murray and myself.

show more ...


Revision tags: llvmorg-19.1.2, llvmorg-19.1.1
# 754c1f21 27-Sep-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] Add debug dump for StackAdjustingInsts (NFC) (#110283)


# e817cfde 27-Sep-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] Refactor generation of push/pop instructions (NFC) (#110283)

These used a set of callback functions to check which callee-save area a
register is in, refactor them to use the same data as othe

[ARM] Refactor generation of push/pop instructions (NFC) (#110283)

These used a set of callback functions to check which callee-save area a
register is in, refactor them to use the same data as other parts of
ARMFrameLowering. This will make it easier to add a new variant to the
register splitting.

show more ...


# 2ecf2e24 25-Sep-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] Factor out code to determine spill areas (NFC) (#110283)

There were multiple loops in ARMFrameLowering which sort the callee
saved registers into spill areas, which were hard to understand and

[ARM] Factor out code to determine spill areas (NFC) (#110283)

There were multiple loops in ARMFrameLowering which sort the callee
saved registers into spill areas, which were hard to understand and
modify. This splits the information about which register is in which
save area into a separate function.

show more ...


# 67200f5d 25-Sep-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] Tidy up stack frame strategy code (NFC) (#110283)

We have two different ways of splitting the pushes of callee-saved
registers onto the stack, controlled by the confusingly similar names
STI.s

[ARM] Tidy up stack frame strategy code (NFC) (#110283)

We have two different ways of splitting the pushes of callee-saved
registers onto the stack, controlled by the confusingly similar names
STI.splitFramePushPop() and STI.splitFramePointerPush(). This removes
those functions and replaces them with a single function which returns
an enum. This is in preparation for adding another value to that enum.

The original work of this patch was done by James Westwood, reviewed as
#82801 and #81249, with some tidy-ups done by Mark Murray and myself.

show more ...


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
# ca076f7a 23-Jul-2024 Wesley Wiser <wwiser@gmail.com>

[LLVM] [MC] Update frame layout & CFI generation to handle frames larger than 2gb (#99263)

Rebase of #84114. I've only included the core changes to frame layout
calculation & CFI generation which s

[LLVM] [MC] Update frame layout & CFI generation to handle frames larger than 2gb (#99263)

Rebase of #84114. I've only included the core changes to frame layout
calculation & CFI generation which sidesteps the regressions found after
merging #84114. Since these changes are a necessary precursor to the
overall fix and are themselves slightly beneficial as CFI is now
generated correctly, I think it is reasonable to merge this first step.

---

For very large stack frames, the offset from the stack pointer to a
local can be more than 2^31 which overflows various `int` offsets in the
frame lowering code.

This patch updates the frame lowering code to calculate the offsets as
64-bit values and fixes CFI to use the corrected sizes.

After this patch, additional work is needed to fix offset truncations in
each target's codegen.

show more ...


Revision tags: llvmorg-20-init
# 0f0cfcff 19-Jul-2024 Matt Arsenault <Matthew.Arsenault@amd.com>

CodeGen: Avoid some references to MachineFunction's getMMI (#99652)

MachineFunction's probably should not include a backreference to
the owning MachineModuleInfo. Most of these references were used

CodeGen: Avoid some references to MachineFunction's getMMI (#99652)

MachineFunction's probably should not include a backreference to
the owning MachineModuleInfo. Most of these references were used
just to query the MCContext, which MachineFunction already directly
stores. Other contexts are using it to query the LLVMContext, which
can already be accessed through the IR function reference.

show more ...


# 3e47f6ba 18-Jul-2024 Kazu Hirata <kazu@google.com>

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

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


# 515618e2 16-Jul-2024 Kazu Hirata <kazu@google.com>

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

This reverts commit 3614f65a7ba9d925010e3316a1d93bcebc632178.

fixupImmediateBr seems to resize ImmBranches.


# 3614f65a 16-Jul-2024 Kazu Hirata <kazu@google.com>

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


Revision tags: llvmorg-18.1.8
# 1a523925 07-Jun-2024 Oliver Stannard <oliver.stannard@arm.com>

[ARM] r11 is reserved when using -mframe-chain=aapcs (#86951)

When using the -mframe-chain=aapcs or -mframe-chain=aapcs-leaf options,
we cannot use r11 as an allocatable register, even if
-fomit-f

[ARM] r11 is reserved when using -mframe-chain=aapcs (#86951)

When using the -mframe-chain=aapcs or -mframe-chain=aapcs-leaf options,
we cannot use r11 as an allocatable register, even if
-fomit-frame-pointer is also used. This is so that r11 will always point
to a valid frame record, even if we don't create one in every function.

show more ...


Revision tags: llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# c12bc57e 30-Apr-2024 Eleanor Bonnici <eleanor.bonnici@arm.com>

Do not use R12 for indirect tail calls with PACBTI (#82661)

When compiling for thumbv8.1m with +pacbti and making an indirect tail
call, the compiler was free to put the function pointer into R12.

Do not use R12 for indirect tail calls with PACBTI (#82661)

When compiling for thumbv8.1m with +pacbti and making an indirect tail
call, the compiler was free to put the function pointer into R12.

This is incorrect because R12 is restored to contain authentication code
for the caller's return address.

This patch excludes R12 from the set of registers the compiler can put
the function pointer in.

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

show more ...


# 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, llvmorg-18.1.3
# 78f0871b 27-Mar-2024 Simon Pilgrim <llvm-dev@redking.me.uk>

Revert rG58de1e2c5eee548a9b365e3b1554d87317072ad9 "Fix stack layout for frames larger than 2gb (#84114)"

This is failing on some EXPENSIVE_CHECKS buildbots


12345678910>>...13