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
|