[CallingConv] Return ArrayRef from AllocateRegBlock() (NFC) (#124120)

Instead of returning the first register, return the ArrayRef containing
the whole block.

Existing users rely on the fact tha

[CallingConv] Return ArrayRef from AllocateRegBlock() (NFC) (#124120)

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.

show more ...

[AArch64] Remove unused includes (NFC) (#115685)

Identified with misc-include-cleaner.

[DataLayout] Change return type of `getStackAlignment` to `MaybeAlign` (#105478)

Currently, `getStackAlignment` asserts if the stack alignment wasn't
specified. This makes it inconvenient to use an

[DataLayout] Change return type of `getStackAlignment` to `MaybeAlign` (#105478)

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.

show more ...

[AArch64][SVE] Lower function arguments in types of arrays of predicates (#90122)

Function arguments in types of arrays of scalable predicates, even in [1 x <vscale x 16 x i1>] type, should be alloc

[AArch64][SVE] Lower function arguments in types of arrays of predicates (#90122)

Function arguments in types of arrays of scalable predicates, even in [1 x <vscale x 16 x i1>] type, should be allocated to available P0 ~ P3 registers, or to the stack and a point of the stack location is passed to the callee.

See details in https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#parameter-passing, step C.7 and C.8

show more ...

[clang][AArch64] Correctly align HFA arguments when passed on the stack

When we pass a AArch64 Homogeneous Floating-Point
Aggregate (HFA) argument with increased alignment
requirements, for example

[clang][AArch64] Correctly align HFA arguments when passed on the stack

When we pass a AArch64 Homogeneous Floating-Point
Aggregate (HFA) argument with increased alignment
requirements, for example

struct S {
__attribute__ ((__aligned__(16))) double v[4];
};

Clang uses `[4 x double]` for the parameter, which is passed
on the stack at alignment 8, whereas it should be at
alignment 16, following Rule C.4 in
AAPCS (https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#642parameter-passing-rules)

Currently we don't have a way to express in LLVM IR the
alignment requirements of the function arguments. The align
attribute is applicable to pointers only, and only for some
special ways of passing arguments (e..g byval). When
implementing AAPCS32/AAPCS64, clang resorts to dubious hacks
of coercing to types, which naturally have the needed
alignment. We don't have enough types to cover all the
cases, though.

This patch introduces a new use of the stackalign attribute
to control stack slot alignment, when and if an argument is
passed in memory.

The attribute align is left as an optimizer hint - it still
applies to pointer types only and pertains to the content of
the pointer, whereas the alignment of the pointer itself is
determined by the stackalign attribute.

For byval arguments, the stackalign attribute assumes the
role, previously perfomed by align, falling back to align if
stackalign` is absent.

On the clang side, when passing arguments using the "direct"
style (cf. `ABIArgInfo::Kind`), now we can optionally
specify an alignment, which is emitted as the new
`stackalign` attribute.

Patch by Momchil Velikov and Lucas Prates.

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

show more ...

[SVE] Deal with SVE tuple call arguments correctly when running out of registers

When passing SVE types as arguments to function calls we can run
out of hardware SVE registers. This is normally fine

[SVE] Deal with SVE tuple call arguments correctly when running out of registers

When passing SVE types as arguments to function calls we can run
out of hardware SVE registers. This is normally fine, since we
switch to an indirect mode where we pass a pointer to a SVE stack
object in a GPR. However, if we switch over part-way through
processing a SVE tuple then part of it will be in registers and
the other part will be on the stack.

I've fixed this by ensuring that:

1. When we don't have enough registers to allocate the whole block
we mark any remaining SVE registers temporarily as allocated.
2. We temporarily remove the InConsecutiveRegs flags from the last
tuple part argument and reinvoke the autogenerated calling
convention handler. Doing this prevents the code from entering
an infinite recursion and, in combination with 1), ensures we
switch over to the Indirect mode.
3. After allocating a GPR register for the pointer to the tuple we
then deallocate any SVE registers we marked as allocated in 1).
We also set the InConsecutiveRegs flags back how they were before.
4. I've changed the AArch64ISelLowering LowerCALL and
LowerFormalArguments functions to detect the start of a tuple,
which involves allocating a single stack object and doing the
correct numbers of legal loads and stores.

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

show more ...

[SVE] Add fatal error when running out of registers for SVE tuple call arguments

When passing SVE types as arguments to function calls we can run
out of hardware SVE registers. This is normally fine

[SVE] Add fatal error when running out of registers for SVE tuple call arguments

When passing SVE types as arguments to function calls we can run
out of hardware SVE registers. This is normally fine, since we
switch to an indirect mode where we pass a pointer to a SVE stack
object in a GPR. However, if we switch over part-way through
processing a SVE tuple then part of it will be in registers and
the other part will be on the stack. This is wrong and we'd like
to avoid any silent ABI compatibility issues in future. For now,
I've added a fatal error when this happens until we can get a
proper fix.

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

show more ...

[Alignment][NFC] Use Align for TargetCallingConv::OrigAlign

This patch replaces D69249.

This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.l

[Alignment][NFC] Use Align for TargetCallingConv::OrigAlign

This patch replaces D69249.

This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

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

show more ...

[Alignment][NFC] Migrate part of Arm/AArch64 backend

Summary: Follow up on D81196

Reviewers: courbet

Subscribers: kristof.beyls, hiraditya, danielkiss, llvm-commits

Tags: #llvm

Differential Revi

[Alignment][NFC] Migrate part of Arm/AArch64 backend

Summary: Follow up on D81196

Reviewers: courbet

Subscribers: kristof.beyls, hiraditya, danielkiss, llvm-commits

Tags: #llvm

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

show more ...

[Alignment][NFC] Remove unneeded llvm:: scoping on Align types

llvm-svn: 373081

[Alignment] Get DataLayout::StackAlignment as Align

Summary:
Internally it is needed to know if StackAlignment is set but we can
expose it as llvm::Align.

This is patch is part of a series to intro

[Alignment] Get DataLayout::StackAlignment as Align

Summary:
Internally it is needed to know if StackAlignment is set but we can
expose it as llvm::Align.

This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 372585

show more ...

AArch64: support arm64_32, an ILP32 slice for watchOS.

This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM.
FastISel is mostly disabled for now since it would generate incorre

AArch64: support arm64_32, an ILP32 slice for watchOS.

This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM.
FastISel is mostly disabled for now since it would generate incorrect code for
ILP32.

llvm-svn: 371722

show more ...

[AArch64] Include AArch64GenCallingConv.inc once

Summary:
Avoids duplicating generated static helpers for calling convention
analysis.

This also means you can modify AArch64CallingConv.td without r

[AArch64] Include AArch64GenCallingConv.inc once

Summary:
Avoids duplicating generated static helpers for calling convention
analysis.

This also means you can modify AArch64CallingConv.td without recompiling
the AArch64ISelLowering.cpp monolith, so it provides faster incremental
rebuilds.

Saves 12K in llc.exe, but adds a new object file, which is large.

Reviewers: efriedma, t.p.northover

Subscribers: mgorny, javed.absar, kristof.beyls, hiraditya, llvm-commits

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

llvm-svn: 352430

show more ...