Revert "[AArch64] Add soft-float ABI (#74460)" (#82032)

This reverts commit 9cc98e336980f00cbafcbed8841344e6ac472bdc.

Issue: https://github.com/ClangBuiltLinux/linux/issues/1997

[AArch64] Add soft-float ABI (#74460)

This adds support for the AArch64 soft-float ABI. The specification for
this ABI was added by https://github.com/ARM-software/abi-aa/pull/232.

Because all e

[AArch64] Add soft-float ABI (#74460)

This adds support for the AArch64 soft-float ABI. The specification for
this ABI was added by https://github.com/ARM-software/abi-aa/pull/232.

Because all existing AArch64 hardware has floating-point hardware, we
expect this to be a niche option, only used for embedded systems on
R-profile systems. We are going to document that SysV-like systems
should only ever use the base (hard-float) PCS variant:
https://github.com/ARM-software/abi-aa/pull/233. For that reason, I've
not added an option to select the ABI independently of the FPU hardware,
instead the new ABI is enabled iff the target architecture does not have
an FPU.

For testing, I have run this through an ABI fuzzer, but since this is
the first implementation it can only test for internal consistency
(callers and callees agree on the PCS), not for conformance to the ABI
spec.

show more ...

[RISCV] Add canonical ISA string as Module metadata in IR. (#80760)

In an LTO build, we don't set the ELF attributes to indicate what
extensions were compiled with. The target CPU/Attrs in
RISCVTa

[RISCV] Add canonical ISA string as Module metadata in IR. (#80760)

In an LTO build, we don't set the ELF attributes to indicate what
extensions were compiled with. The target CPU/Attrs in
RISCVTargetMachine do not get set for an LTO build. Each function gets a
target-cpu/feature attribute, but this isn't usable to set ELF attributs
since we wouldn't know what function to use. We can't just once since it
might have been compiler with an attribute likes target_verson.

This patch adds the ISA as Module metadata so we can retrieve it in the
backend. Individual translation units can still be compiled with
different strings so we need to collect the unique set when Modules are
merged.

The backend will need to combine the unique ISA strings to produce a
single value for the ELF attributes. This will be done in a separate
patch.

show more ...

[clang][fmv] Drop .ifunc from target_version's entrypoint's mangling (#81194)

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

[NFC][Clang] Replace Arch with Triplet. (#80465)

[AArch64] Replace LLVM IR function attributes for PSTATE.ZA. (#79166)

Since https://github.com/ARM-software/acle/pull/276 the ACLE
defines attributes to better describe the use of a given SME state

[AArch64] Replace LLVM IR function attributes for PSTATE.ZA. (#79166)

Since https://github.com/ARM-software/acle/pull/276 the ACLE
defines attributes to better describe the use of a given SME state.

Previously the attributes merely described the possibility of it being
'shared' or 'preserved', whereas the new attributes have more semantics
and also describe how the data flows through the program.

For ZT0 we already had to add new LLVM IR attributes:
* aarch64_new_zt0
* aarch64_in_zt0
* aarch64_out_zt0
* aarch64_inout_zt0
* aarch64_preserves_zt0

We have now done the same for ZA, such that we add:
* aarch64_new_za (previously `aarch64_pstate_za_new`)
* aarch64_in_za (more specific variation of `aarch64_pstate_za_shared`)
* aarch64_out_za (more specific variation of `aarch64_pstate_za_shared`)
* aarch64_inout_za (more specific variation of
`aarch64_pstate_za_shared`)
* aarch64_preserves_za (previously `aarch64_pstate_za_shared,
aarch64_pstate_za_preserved`)

This explicitly removes 'pstate' from the name, because with SME2 and
the new ACLE attributes there is a difference between "sharing ZA"
(sharing
the ZA matrix register with the caller) and "sharing PSTATE.ZA" (sharing
either the ZA or ZT0 register, both part of PSTATE.ZA with the caller).

show more ...

[clang, SystemZ] Support -munaligned-symbols (#73511)

When this option is passed to clang, external (and/or weak) symbols
are not assumed to have the minimum ABI alignment normally required.
Symbo

[clang, SystemZ] Support -munaligned-symbols (#73511)

When this option is passed to clang, external (and/or weak) symbols
are not assumed to have the minimum ABI alignment normally required.
Symbols defined locally that are not weak are however still given the
minimum alignment.

This is implemented by passing a new parameter to getMinGlobalAlign()
named HasNonWeakDef that is used to return the right alignment value.

This is needed when external symbols created from a linker script may
not get the ABI minimum alignment and must therefore be treated as
unaligned by the compiler.

show more ...

[Clang] Amend SME attributes with support for ZT0. (#77941)

This patch builds on top of #76971 and implements support for:
* __arm_new("zt0")
* __arm_in("zt0")
* __arm_out("zt0")
* __arm_inout("

[Clang] Amend SME attributes with support for ZT0. (#77941)

This patch builds on top of #76971 and implements support for:
* __arm_new("zt0")
* __arm_in("zt0")
* __arm_out("zt0")
* __arm_inout("zt0")
* __arm_preserves("zt0")

show more ...

[AArch64][Clang] Fix linker error for function multiversioning (#74358)

AArch64 part of https://github.com/llvm/llvm-project/pull/71706.

Default version is now mangled with .default.
Resolver fo

[AArch64][Clang] Fix linker error for function multiversioning (#74358)

AArch64 part of https://github.com/llvm/llvm-project/pull/71706.

Default version is now mangled with .default.
Resolver for the TargetVersion need to be emitted from the
CodeGenModule::EmitMultiVersionFunctionDefinition.

show more ...

Add a "don't override" mapping for -fvisibility-from-dllstorageclass (#74629)

`-fvisibility-from-dllstorageclass` allows for overriding the visibility
of globals from their DLL storage class. The v

Add a "don't override" mapping for -fvisibility-from-dllstorageclass (#74629)

`-fvisibility-from-dllstorageclass` allows for overriding the visibility
of globals from their DLL storage class. The visibility to apply can be
customised for the different classes of globals via a set of dependent
options that specify the mapping values:
- `-fvisibility-dllexport=<value>`
- `-fvisibility-nodllstorageclass=<value>`
- `-fvisibility-externs-dllimport=<value>`
- `-fvisibility-externs-nodllstorageclass=<value>`

Currently, one of the existing LLVM visibilities, `hidden`, `protected`,
`default`, can be used as a mapping value. This change adds a new
mapping value: `keep`, which specifies that the visibility should not be
overridden for that class of globals. The behaviour of
`-fvisibility-from-dllstorageclass` is otherwise unchanged and existing
uses of this set of options will be unaffected.

The background to this change is that currently the PS4 and PS5
compilers effectively ignore visibility - dllimport/export is the
supported method for export control in C/C++ source code. Now, we would
like to support visibility attributes and options in our frontend, in
addition to dllimport/export. To support this, we will override the
visibility of globals with explicit dllimport/export annotations but use
the `keep` setting for globals which do not have an explicit
dllimport/export.

There are also some minor improvements to the existing options:
- Make the `LANGOPS` `BENIGN` as they don't involve the AST.
- Correct/clarify the help text for the options.

show more ...

[RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (#76777)

This commit includes the necessary changes to clang and LLVM to support
codegen of `RVE` and the `ilp32e`/`lp64e` ABIs.

The differences between

[RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (#76777)

This commit includes the necessary changes to clang and LLVM to support
codegen of `RVE` and the `ilp32e`/`lp64e` ABIs.

The differences between `RVE` and `RVI` are:
* `RVE` reduces the integer register count to 16(x0-x16).
* The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits.

`RVE` can be combined with all current standard extensions.

The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are:
* Only 6 integer argument registers (rather than 8).
* Only 2 callee-saved registers (rather than 12).
* A Stack Alignment of 32bits (rather than 128bits).
* ilp32e isn't compatible with D ISA extension.

If `ilp32e` or `lp64` is used with an ISA that has any of the registers
x16-x31 and f0-f31, then these registers are considered temporaries.

To be compatible with the implementation of ilp32e in GCC, we don't use
aligned registers to pass variadic arguments and set stack alignment\
to 4-bytes for types with length of 2*XLEN.

FastCC is also supported on RVE, while GHC isn't since there is only one
avaiable register.

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

show more ...

[Clang][AArch64] Change SME attributes for shared/new/preserved state. (#76971)

This patch replaces the `__arm_new_za`, `__arm_shared_za` and
`__arm_preserves_za` attributes in favour of:
* `__arm

[Clang][AArch64] Change SME attributes for shared/new/preserved state. (#76971)

This patch replaces the `__arm_new_za`, `__arm_shared_za` and
`__arm_preserves_za` attributes in favour of:
* `__arm_new("za")`
* `__arm_in("za")`
* `__arm_out("za")`
* `__arm_inout("za")`
* `__arm_preserves("za")`

As described in https://github.com/ARM-software/acle/pull/276.

One change is that `__arm_in/out/inout/preserves(S)` are all mutually
exclusive, whereas previously it was fine to write `__arm_shared_za
__arm_preserves_za`. This case is now represented with `__arm_in("za")`.

The current implementation uses the same LLVM attributes under the hood,
since `__arm_in/out/inout` are all variations of "shared ZA", so can use
the existing `aarch64_pstate_za_shared` attribute in LLVM.

#77941 will add support for the new "zt0" state as introduced
with SME2.

show more ...

[clang] Adjust -mlarge-data-threshold handling (#77958)

Make it apply to x86-64 medium and large code models since that's what
the backend does.

Limit logic to exclude x86-32.

Default to 0, l

[clang] Adjust -mlarge-data-threshold handling (#77958)

Make it apply to x86-64 medium and large code models since that's what
the backend does.

Limit logic to exclude x86-32.

Default to 0, let the driver set it to 65536 for the medium code model
if one is not passed. Set it to 0 for the large code model by default to
match gcc and since some users make assumptions about the large code
model that any small data will break.

show more ...

[clang][AArch64] Add a -mbranch-protection option to enable GCS (#75486)

-mbranch-protection=gcs (enabled by -mbranch-protection=standard) causes
generated objects to be marked with the gcs feature

[clang][AArch64] Add a -mbranch-protection option to enable GCS (#75486)

-mbranch-protection=gcs (enabled by -mbranch-protection=standard) causes
generated objects to be marked with the gcs feature. This is done via
the guarded-control-stack module flag, in a similar way to
branch-target-enforcement and sign-return-address.

Enabling GCS causes the GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit to be set
on generated objects. No code generation changes are required, as GCS
just requires that functions are called using BL and returned from using
RET (or other similar variant instructions), which is already the case.

show more ...

[clang] Add per-global code model attribute (#72078)

This patch adds a per-global code model attribute, which can override
the target's code model to access global variables.

Currently, the code

[clang] Add per-global code model attribute (#72078)

This patch adds a per-global code model attribute, which can override
the target's code model to access global variables.

Currently, the code model attribute is only supported on LoongArch. This
patch also maps GCC's code model names to LLVM's, which allows for
better compatibility between the two compilers.


Suggested-by: Arthur Eubanks <aeubanks@google.com>
Link:
https://discourse.llvm.org/t/how-to-best-implement-code-model-overriding-for-certain-values/71816
Link:
https://discourse.llvm.org/t/rfc-add-per-global-code-model-attribute/74944

---------

Signed-off-by: WANG Rui <wangrui@loongson.cn>

show more ...

Re-land "[AArch64] Codegen support for FEAT_PAuthLR" (#75947)

This reverts commit 9f0f5587426a4ff24b240018cf8bf3acc3c566ae.

Fix expensive checks failure by properly marking register def for ADR.

Revert "[AArch64] Codegen support for FEAT_PAuthLR"

This reverts commit 5992ce90b8c0fac06436c3c86621fbf6d5398ee5.

Builtbot failures with expensive checks enabled.

[AArch64] Codegen support for FEAT_PAuthLR

- Adds a new +pc option to -mbranch-protection that will enable
the use of PC as a diversifier in PAC branch protection code.

- When +pauth-lr is enable

[AArch64] Codegen support for FEAT_PAuthLR

- Adds a new +pc option to -mbranch-protection that will enable
the use of PC as a diversifier in PAC branch protection code.

- When +pauth-lr is enabled (-march=armv9.5a+pauth-lr) in combination
with -mbranch-protection=pac-ret+pc, the new 9.5-a instructions
(pacibsppc, retaasppc, etc) are used.

Documentation for the relevant instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2023-09/Base-Instructions/

Co-authored-by: Lucas Prates <lucas.prates@arm.com>

show more ...

[clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLA

[clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is
supposed to be a string, as it is defined (optionally) as such in the
top-level clang `CMakeLists.txt`.

Furthermore, `CLANG_VENDOR` is only passed as a build-time define when
compiling `Version.cpp`, so add a `getClangVendor()` function to
`Version.h`, and use it in `CodegGenModule.cpp`, instead of relying on
the macro.

Fixes: 9a38a72f1d482

show more ...

Revert "[clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)"

This reverts commit 9055519103eadfba0b48810be926883a71890c55, due to an
incorrectly chosen commit message.

[clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CL

[clang] Add getClangVendor() and use it in CodeGenModule.cpp (#75935)

In 9a38a72f1d482 `ProductId` was assigned from the stringified value of
`CLANG_VENDOR`, if that macro was defined. However, `CLANG_VENDOR` is
supposed to be a string, as it is defined (optionally) as such in the
top-level clang `CMakeLists.txt`.

Move the addition of `-DCLANG_VENDOR` to the compiler flags from
`clang/lib/Basic/CMakeLists.txt` to the top-level `CMakeLists.txt`, so
it is consistent across the whole clang codebase. Then remove the
stringification from `CodeGenModule.cpp`, to make it work correctly.

Fixes: 9a38a72f1d482

show more ...

[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}:

[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[NFC] Remove unneeded nullptr checks after cast<> (#74674)

Since VD is assigned from a cast<VarDecl> it cannot be a nullptr or it
would have asserted. Remove the subsequent checks to clear up any

[NFC] Remove unneeded nullptr checks after cast<> (#74674)

Since VD is assigned from a cast<VarDecl> it cannot be a nullptr or it
would have asserted. Remove the subsequent checks to clear up any
misunderstanding.

show more ...

[Clang] Fix linker error for function multiversioning (#71706)

Currently target_clones attribute results in a linker error when there
are no multi-versioned function declarations in the calling TU

[Clang] Fix linker error for function multiversioning (#71706)

Currently target_clones attribute results in a linker error when there
are no multi-versioned function declarations in the calling TU.

In the calling TU, the call is generated with the ‘normal’ assembly
name. This does not match any of the versions or the ifunc, since
version mangling includes a .versionstring, and the ifunc includes
.ifunc suffix. The linker error is not seen with GCC since the mangling
for the ifunc symbol in GCC is the ‘normal’ assembly name for function
i.e. no ifunc suffix.

This PR removes the .ifunc suffix to match GCC. It also adds alias with
the .ifunc suffix so as to ensure backward compatibility.

The changes exclude aarch64 target because the mangling for default
versions on aarch64 does not include a .default suffix and is the
'normal' assembly name, unlike other targets. It is not clear to me what
the correct behavior for this target is.

Old Phabricator review - https://reviews.llvm.org/D158666

---------

Co-authored-by: Tom Honermann <tom@honermann.net>

show more ...

[clang][AArch64] Pass down stack clash protection options to LLVM/Backend (#68993)