[AArch64] Match GCC behaviour for zero-size structs (#124760)

We had a test claiming that this empty struct type consumes a register
slot when passing it to a function with GCC, but that does not a

[AArch64] Match GCC behaviour for zero-size structs (#124760)

We had a test claiming that this empty struct type consumes a register
slot when passing it to a function with GCC, but that does not appear to
be the case, at least with GCC versions going back to 4.8.

This also caused a miscompilation when passing one of these structs to a
variadic function, but it turned out that our implementation of `va_arg`
matches GCC's ABI, so the one change fixes both bugs.

show more ...

[AArch64] Refactor implementation of FP8 types (NFC) (#123604)

- The FP8 scalar type (`__mfp8`) was described as a vector type
- The FP8 vector types were described/assumed to have integer element

[AArch64] Refactor implementation of FP8 types (NFC) (#123604)

- The FP8 scalar type (`__mfp8`) was described as a vector type
- The FP8 vector types were described/assumed to have integer element
type (the element type ought to be `__mfp8`)
- Add support for `m` type specifier (denoting `__mfp8`) in
`DecodeTypeFromStr` and create builtin function prototypes using that
specifier, instead of `int8_t`

show more ...

[AArch64] Implement NEON FP8 vectors as VectorType (#123603)

Reimplement Neon FP8 vector types using attribute `neon_vector_type`
instead of having them as builtin types.
This allows to implement

[AArch64] Implement NEON FP8 vectors as VectorType (#123603)

Reimplement Neon FP8 vector types using attribute `neon_vector_type`
instead of having them as builtin types.
This allows to implement FP8 Neon intrinsics without the need to add
special cases for these types when using `__builtin_shufflevector`
or bitcast (using C-style cast operator) between vectors, both
extensively used in the generated code in `arm_neon.h`.

show more ...

[AArch64][SME] Disable inlining of callees with new ZT0 state (#121338)

Inlining must be disabled for new-ZT0 callees as the callee is required
to save ZT0 and toggle PSTATE.ZA on entry.

AArch64ABIInfo::passAsAggregateType - don't directly dereference getAs<> result. NFC.

Reported by coverity static analyzer - we know the type is a BuiltinType so use castAs<>

[AArch64] Fix argument passing for SVE tuples (#118961)

The fix for passing Pure Scalable Types
(https://github.com/llvm/llvm-project/pull/112747) was incomplete,
it didn't handle correctly tuples

[AArch64] Fix argument passing for SVE tuples (#118961)

The fix for passing Pure Scalable Types
(https://github.com/llvm/llvm-project/pull/112747) was incomplete,
it didn't handle correctly tuples of SVE vectors (e.g. `sveboolx2_t`,
`svfloat32x4_t`, etc).

These types are Pure Scalable Types and should be passed either entirely
in vector registers
or indirectly in memory, not split.

show more ...

[clang][SME] Ignore flatten/clang::always_inline statements for callees with mismatched streaming attributes (#116391)

If `__attribute__((flatten))` is used on a function, or
`[[clang::always_inlin

[clang][SME] Ignore flatten/clang::always_inline statements for callees with mismatched streaming attributes (#116391)

If `__attribute__((flatten))` is used on a function, or
`[[clang::always_inline]]` on a statement, don't inline any callees with
incompatible streaming attributes. Without this check, clang may produce
incorrect code when these attributes are used in code with streaming
functions.

Note: The docs for flatten say it can be ignored when inlining is
impossible: "causes calls within the attributed function to be inlined
unless it is impossible to do so".

Similarly, the (clang-only) `[[clang::always_inline]]` statement
attribute is more relaxed than the GNU `__attribute__((always_inline))`
(which says it should error it if it can't inline), saying only "If a
statement is marked [[clang::always_inline]] and contains calls, the
compiler attempts to inline those calls.". The docs also go on to show
an example of where `[[clang::always_inline]]` has no effect.

show more ...

Remove support for RenderScript (#112916)

See
https://discourse.llvm.org/t/rfc-deprecate-and-eventually-remove-renderscript-support/81284
for the RFC

[Clang][AArch64] Fix Pure Scalables Types argument passing and return (#112747)

Pure Scalable Types are defined in AAPCS64 here:

https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.r

[Clang][AArch64] Fix Pure Scalables Types argument passing and return (#112747)

Pure Scalable Types are defined in AAPCS64 here:

https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#pure-scalable-types-psts

And should be passed according to Rule C.7 here:

https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#682parameter-passing-rules

This part of the ABI is completely unimplemented in Clang, instead it
treats PSTs sometimes as HFAs/HVAs, sometime as general composite types.

This patch implements the rules for passing PSTs by employing the
`CoerceAndExpand` method and extending it to:
* allow array types in the `coerceToType`; Now only `[N x i8]` are
considered padding.
* allow mismatch between the elements of the `coerceToType` and the
elements of the `unpaddedCoerceToType`; AArch64 uses this to map
fixed-length vector types to SVE vector types.

Corectly passing a PST argument needs a decision in Clang about whether
to pass it in memory or registers or, equivalently, whether to use the
`Indirect` or `Expand/CoerceAndExpand` method. It was considered
relatively harder (or not practically possible) to make that decision in
the AArch64 backend.
Hence this patch implements the register counting from AAPCS64 (cf.
`NSRN`, `NPRN`) to guide the Clang's decision.

show more ...

[clang][AArch64] Put soft-float ABI checks under isSoftFloat(). NFC

Fix codegen for transparent_union function params (#104816)

Update codegen for func param with transparent_union attr to be that of
the first union member.

This is a followup to #101738 to fix n

Fix codegen for transparent_union function params (#104816)

Update codegen for func param with transparent_union attr to be that of
the first union member.

This is a followup to #101738 to fix non-ppc codegen and closes #76773.

show more ...

[clang][AArch64] Point the nofp ABI check diagnostics at the callee (#103392)

... whereever we have the Decl for it, and even when we don't keep the
SourceLocation of it aimed at the call site.

[clang][AArch64] Point the nofp ABI check diagnostics at the callee (#103392)

... whereever we have the Decl for it, and even when we don't keep the
SourceLocation of it aimed at the call site.

Fixes: #102983

show more ...

Reland: "[Clang] Demote always_inline error to warning for mismatching SME attrs" (#100991) (#100996)

Test `aarch64-sme-inline-streaming-attrs.c` caused some buildbot
failures, because the test was

Reland: "[Clang] Demote always_inline error to warning for mismatching SME attrs" (#100991) (#100996)

Test `aarch64-sme-inline-streaming-attrs.c` caused some buildbot
failures, because the test was missing a `REQUIRES: aarch64-registered
target`. This was because we've demoted the error to a warning, which
then resulted in a different error message, because Clang can't actually
CodeGen the IR.

show more ...

Revert "[Clang] Demote always_inline error to warning for mismatching SME attrs" (#100991)

Reverts llvm/llvm-project#100740

[Clang] Demote always_inline error to warning for mismatching SME attrs (#100740)

PR #77936 introduced a diagnostic to avoid calls being inlined into
functions with a different streaming mode, beca

[Clang] Demote always_inline error to warning for mismatching SME attrs (#100740)

PR #77936 introduced a diagnostic to avoid calls being inlined into
functions with a different streaming mode, because inlining those
functions may result in different runtime behaviour. This was necessary
because LLVM doesn't check whether inlining is possible and thus blindly
inlines the function without checking feasibility.

In practice however, this introduces an artificial restriction that the
user may not be able to work around. Calling an `always_inline` function
from some header file that is out of the control of the user would
result in an error that the user cannot remedy.

Therefore, this patch demotes the error into a warning (for calls from
streaming[-compatible] -> non-streaming), but the proper fix would be to
fix the AlwaysInliner in LLVM to avoid inlining when it has analyzed the
callee and has determined that inlining is not possible.

Calling an always_inline function for calls from non-streaming ->
streaming will remain an error, because there is little pre-existing
code for SME, so it is expected that the header file can be modified by
the user (e.g. by using `__arm_streaming_compatible` if the code is
claimed to be compatible).

show more ...

[NFC][Clang] Move set functions out BranchProtectionInfo. (#98451)

To reduce build times move them to TargetCodeGenInfo.

Refactor of #98329

[Clang][ARM][AArch64] Alway emit protection attributes for functions. (#82819)

So far branch protection, sign return address, guarded control stack
attributes are
only emitted as module flags to ind

[Clang][ARM][AArch64] Alway emit protection attributes for functions. (#82819)

So far branch protection, sign return address, guarded control stack
attributes are
only emitted as module flags to indicate the functions need to be
generated with
those features.
The problem is in case of an LTO build the module flags are merged with
the `min`
rule which means if one of the module is not build with sign return
address then the features
will be turned off for all functions. Due to the functions take the
branch-protection and
sign-return-address features from the module flags. The
sign-return-address is
function level option therefore it is expected functions from files that
is
compiled with -mbranch-protection=pac-ret to be protected.
The inliner might inline functions with different set of flags as it
doesn't consider
the module flags.

This patch adds the attributes to all functions and drops the checking
of the module flags
for the code generation.
Module flag is still used for generating the ELF markers.
Also drops the "true"/"false" values from the
branch-protection-enforcement,
branch-protection-pauth-lr, guarded-control-stack attributes as presence
of the
attribute means it is on absence means off and no other option.

Releand with test fixes.

show more ...

Revert "[Clang][ARM][AArch64] Alway emit protection attributes for functions." (#98284)

Reverts llvm/llvm-project#82819

[Clang][ARM][AArch64] Alway emit protection attributes for functions. (#82819)

So far branch protection, sign return address, guarded control stack
attributes are
only emitted as module flags to i

[Clang][ARM][AArch64] Alway emit protection attributes for functions. (#82819)

So far branch protection, sign return address, guarded control stack
attributes are
only emitted as module flags to indicate the functions need to be
generated with
those features.
The problem is in case of an LTO build the module flags are merged with
the `min`
rule which means if one of the module is not build with sign return
address then the features
will be turned off for all functions. Due to the functions take the
branch-protection and
sign-return-address features from the module flags. The
sign-return-address is
function level option therefore it is expected functions from files that
is
compiled with -mbranch-protection=pac-ret to be protected.
The inliner might inline functions with different set of flags as it
doesn't consider
the module flags.

This patch adds the attributes to all functions and drops the checking
of the module flags
for the code generation.
Module flag is still used for generating the ELF markers.
Also drops the "true"/"false" values from the
branch-protection-enforcement,
branch-protection-pauth-lr, guarded-control-stack attributes as presence
of the
attribute means it is on absence means off and no other option.

show more ...

[AArch64][TargetParser] Split FMV and extensions (#92882)

FMV extensions are really just mappings from FMV feature names to lists
of backend features for codegen. Split them out into their own sepa

[AArch64][TargetParser] Split FMV and extensions (#92882)

FMV extensions are really just mappings from FMV feature names to lists
of backend features for codegen. Split them out into their own separate
file.

show more ...

[clang][CodeGen] Return RValue from `EmitVAArg` (#94635)

This should simplify handling of resulting value by the callers.

[AArch64] Use ptrmask for vaarg stack alignment (#92836)

[Clang] Fix incorrect passing of _BitInt args (#90741)

This patch removes incorrect `byval` attribute from pointer argument
passed with >128 bit long _BitInt types.

[Clang][AArch64] NFC: Add IsArmStreamingFunction.

Simple refactoring to make a single interface that checks if a
FunctionDecl is a __arm[_locally]_streaming function.

[AArch64] Diagnose more functions when FP not enabled (#90832)

When using a hard-float ABI for a target without FP registers, it's not
possible to correctly generate code for functions with argumen

[AArch64] Diagnose more functions when FP not enabled (#90832)

When using a hard-float ABI for a target without FP registers, it's not
possible to correctly generate code for functions with arguments which
must be passed in floating-point registers. This is diagnosed in CodeGen
instead of Sema, to more closely match GCC's behaviour around inline
functions, which is relied on by the Linux kernel.

Previously, this only checked function signatures as they were
code-generated, but this missed some cases:
* Calls to functions not defined in this translation unit.
* Calls through function pointers.
* Calls to variadic functions, where the variadic arguments have a
floating-point type.

This adds checks to function calls, as well as definitions, so that
these cases are correctly diagnosed.

show more ...