llvm-project.git/llvm/lib/Target/ARM/ARMCallingConv.cpp, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. [ARM] Fix calling convention for __fp16 with big-endian (#126741) 2025-02-13T09:09:29+00:00 Oliver Stannard oliver.stannard@arm.com 2025-02-13T09:09:29+00:00 308ce8d5240875911987b63fa6579c87758ab4ac AAPCS32 defines the fp16 and bf16 types as being passed as if they were extended to 32 bits, with the high 16 bits being unspecified. The extension is specified as happening as-if it was done in a register, which means that for big endian targets, the actual value gets passed in the higher addressed half of the stack slot, instead of the lower addressed half as for little endian. Previously, for targets with the fp16 extension, we were passing these types as a 16 bit stack slot, which worked for little endian because every later stack slot would be 4-byte aligned leaving the 2 byte gap, but was incorrect for big endian. 
AAPCS32 defines the fp16 and bf16 types as being passed as if they were
extended to 32 bits, with the high 16 bits being unspecified. The
extension is specified as happening as-if it was done in a register,
which means that for big endian targets, the actual value gets passed in
the higher addressed half of the stack slot, instead of the lower
addressed half as for little endian. Previously, for targets with the
fp16 extension, we were passing these types as a 16 bit stack slot,
which worked for little endian because every later stack slot would be
4-byte aligned leaving the 2 byte gap, but was incorrect for big endian.
 [CallingConv] Return ArrayRef from AllocateRegBlock() (NFC) (#124120) 2025-01-23T15:33:49+00:00 Nikita Popov npopov@redhat.com 2025-01-23T15:33:49+00:00 6fe0fc60341b05bf30ccc16012dab9eeb55a338d Instead of returning the first register, return the ArrayRef containing the whole block. Existing users rely on the fact that the register block only contains adjacently-numbered registers and it's possible to get the remaining registers in the block by just incrementing the register. Returning an ArrayRef allows more generic usage with non-adjacent registers. 
Instead of returning the first register, return the ArrayRef containing
the whole block.

Existing users rely on the fact that the register block only contains
adjacently-numbered registers and it's possible to get the remaining
registers in the block by just incrementing the register. Returning an
ArrayRef allows more generic usage with non-adjacent registers.
 [ARM] Remove unused includes (NFC) (#115995) 2024-11-13T07:15:21+00:00 Kazu Hirata kazu@google.com 2024-11-13T07:15:21+00:00 9571cc2b28d74c20f1abb3280adaa42d6e5b88dc Identified with misc-include-cleaner. 
Identified with misc-include-cleaner.
 [DataLayout] Change return type of `getStackAlignment` to `MaybeAlign` (#105478) 2024-08-27T19:59:33+00:00 Sergei Barannikov barannikov88@gmail.com 2024-08-27T19:59:33+00:00 4d7a0abae8b40482a44c22257b2e86c6fa89547c Currently, `getStackAlignment` asserts if the stack alignment wasn't specified. This makes it inconvenient to use and complicates testing. This change also makes `exceedsNaturalStackAlignment` method redundant. 
Currently, `getStackAlignment` asserts if the stack alignment wasn't
specified. This makes it inconvenient to use and complicates testing.

This change also makes `exceedsNaturalStackAlignment` method redundant.
 [CodeGen] Use MCRegister for CCState::AllocateReg and CCValAssign::getReg. NFC (#106032) 2024-08-26T18:40:25+00:00 Craig Topper craig.topper@sifive.com 2024-08-26T18:40:25+00:00 4b0c0ec6b8065e611640f44adce94e2da12b3a3a 






[CodeGen] Replace CCState's getNextStackOffset with getStackSize (NFC)
2023-05-17T18:51:45+00:00

Sergei Barannikov
barannikov88@gmail.com

2023-05-01T02:39:30+00:00

01a796744745d8413d0821c734caf2fbe19f2eca

The term "next stack offset" is misleading because the next argument is
not necessarily allocated at this offset due to alignment constrains.
It also does not make much sense when allocating arguments at negative
offsets (introduced in a follow-up patch), because the returned offset
would be past the end of the next argument.

Reviewed By: arsenm

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





The term "next stack offset" is misleading because the next argument is
not necessarily allocated at this offset due to alignment constrains.
It also does not make much sense when allocating arguments at negative
offsets (introduced in a follow-up patch), because the returned offset
would be past the end of the next argument.

Reviewed By: arsenm

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







[ARM] Use range-based for loops (NFC)
2021-12-21T07:06:47+00:00

Kazu Hirata
kazu@google.com

2021-12-21T07:06:47+00:00

c5cf7d910e54310450e9ad758d93ef1c0c83f8e1












Revert "[ARM] Use range-based for loops (NFC)"
2021-12-20T18:51:36+00:00

Kazu Hirata
kazu@google.com

2021-12-20T18:51:36+00:00

de904900600f11a65cdf44023061600b668e9df5

This reverts commit 93d79cac2ede436e1e3e91b5aff702914cdfbca7.

This patch seems to break
llvm/test/CodeGen/ARM/constant-islands-cfg.mir under asan.





This reverts commit 93d79cac2ede436e1e3e91b5aff702914cdfbca7.

This patch seems to break
llvm/test/CodeGen/ARM/constant-islands-cfg.mir under asan.







[ARM] Use range-based for loops (NFC)
2021-12-20T08:04:53+00:00

Kazu Hirata
kazu@google.com

2021-12-20T08:04:52+00:00

93d79cac2ede436e1e3e91b5aff702914cdfbca7












[clang][AArch32] Correctly align HA arguments when passed on the stack
2021-05-10T15:28:46+00:00

Momchil Velikov
momchil.velikov@arm.com

2021-05-10T13:53:21+00:00

5c7b43aa8298a389b906d72c792941a0ce57782e

Analogously to https://reviews.llvm.org/D98794 this patch uses the
`alignstack` attribute to fix incorrect passing of homogeneous
aggregate (HA) arguments on AArch32. The EABI/AAPCS was recently
updated to clarify how VFP co-processor candidates are aligned:
https://github.com/ARM-software/abi-aa/commit/4488e34998514dc7af5507236f279f6881eede62

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





Analogously to https://reviews.llvm.org/D98794 this patch uses the
`alignstack` attribute to fix incorrect passing of homogeneous
aggregate (HA) arguments on AArch32. The EABI/AAPCS was recently
updated to clarify how VFP co-processor candidates are aligned:
https://github.com/ARM-software/abi-aa/commit/4488e34998514dc7af5507236f279f6881eede62

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