[FMV][AArch64] Simplify version selection according to ACLE. (#121921)

Currently, the more features a version has, the higher its priority is.
We are changing ACLE https://github.com/ARM-software/a

[FMV][AArch64] Simplify version selection according to ACLE. (#121921)

Currently, the more features a version has, the higher its priority is.
We are changing ACLE https://github.com/ARM-software/acle/pull/370 as
follows:

"Among any two versions, the higher priority version is determined by
identifying the highest priority feature that is specified in exactly
one of the versions, and selecting that version."

show more ...

Revert "Switch builtin strings to use string tables" (#119638)

Reverts llvm/llvm-project#118734

There are currently some specific versions of MSVC that are miscompiling
this code (we think). We

Revert "Switch builtin strings to use string tables" (#119638)

Reverts llvm/llvm-project#118734

There are currently some specific versions of MSVC that are miscompiling
this code (we think). We don't know why as all the other build bots and
at least some folks' local Windows builds work fine.

This is a candidate revert to help the relevant folks catch their
builders up and have time to debug the issue. However, the expectation
is to roll forward at some point with a workaround if at all possible.

show more ...

Switch builtin strings to use string tables (#118734)

The Clang binary (and any binary linking Clang as a library), when built
using PIE, ends up with a pretty shocking number of dynamic relocation

Switch builtin strings to use string tables (#118734)

The Clang binary (and any binary linking Clang as a library), when built
using PIE, ends up with a pretty shocking number of dynamic relocations
to apply to the executable image: roughly 400k.

Each of these takes up binary space in the executable, and perhaps most
interestingly takes start-up time to apply the relocations.

The largest pattern I identified were the strings used to describe
target builtins. The addresses of these string literals were stored into
huge arrays, each one requiring a dynamic relocation. The way to avoid
this is to design the target builtins to use a single large table of
strings and offsets within the table for the individual strings. This
switches the builtin management to such a scheme.

This saves over 100k dynamic relocations by my measurement, an over 25%
reduction. Just looking at byte size improvements, using the `bloaty`
tool to compare a newly built `clang` binary to an old one:

```
FILE SIZE VM SIZE
-------------- --------------
+1.4% +653Ki +1.4% +653Ki .rodata
+0.0% +960 +0.0% +960 .text
+0.0% +197 +0.0% +197 .dynstr
+0.0% +184 +0.0% +184 .eh_frame
+0.0% +96 +0.0% +96 .dynsym
+0.0% +40 +0.0% +40 .eh_frame_hdr
+114% +32 [ = ] 0 [Unmapped]
+0.0% +20 +0.0% +20 .gnu.hash
+0.0% +8 +0.0% +8 .gnu.version
+0.9% +7 +0.9% +7 [LOAD #2 [R]]
[ = ] 0 -75.4% -3.00Ki .relro_padding
-16.1% -802Ki -16.1% -802Ki .data.rel.ro
-27.3% -2.52Mi -27.3% -2.52Mi .rela.dyn
-1.6% -2.66Mi -1.6% -2.66Mi TOTAL
```

We get a 16% reduction in the `.data.rel.ro` section, and nearly 30%
reduction in `.rela.dyn` where those reloctaions are stored.

This is also visible in my benchmarking of binary start-up overhead at
least:

```
Benchmark 1: ./old_clang --version
Time (mean ± σ): 17.6 ms ± 1.5 ms [User: 4.1 ms, System: 13.3 ms]
Range (min … max): 14.2 ms … 22.8 ms 162 runs

Benchmark 2: ./new_clang --version
Time (mean ± σ): 15.5 ms ± 1.4 ms [User: 3.6 ms, System: 11.8 ms]
Range (min … max): 12.4 ms … 20.3 ms 216 runs

Summary
'./new_clang --version' ran
1.13 ± 0.14 times faster than './old_clang --version'
```

We get about 2ms faster `--version` runs. While there is a lot of noise
in binary execution time, this delta is pretty consistent, and
represents over 10% improvement. This is particularly interesting to me
because for very short source files, repeatedly starting the `clang`
binary is actually the dominant cost. For example, `configure` scripts
running against the `clang` compiler are slow in large part because of
binary start up time, not the time to process the actual inputs to the
compiler.

----

This PR implements the string tables using `constexpr` code and the
existing macro system. I understand that the builtins are moving towards
a TableGen model, and if complete that would provide more options for
modeling this. Unfortunately, that migration isn't complete, and even
the parts that are migrated still rely on the ability to break out of
the TableGen model and directly expand an X-macro style `BUILTIN(...)`
textually. I looked at trying to complete the move to TableGen, but it
would both require the difficult migration of the remaining targets, and
solving some tricky problems with how to move away from any macro-based
expansion.

I was also able to find a reasonably clean and effective way of doing
this with the existing macros and some `constexpr` code that I think is
clean enough to be a pretty good intermediate state, and maybe give a
good target for the eventual TableGen solution. I was also able to
factor the macros into set of consistent patterns that avoids a
significant regression in overall boilerplate.

show more ...

[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)

Currently we have code with target hooks in CodeGenModule shared between
X86 and AArch64 for sorting MultiVersionResol

[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)

Currently we have code with target hooks in CodeGenModule shared between
X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used
when generating IFunc resolvers for FMV. The RISCV target has different
criteria for sorting, therefore it repeats sorting after calling
CodeGenFunction::EmitMultiVersionResolver.

I am moving the FMV priority logic in TargetInfo, so that it can be
implemented by the TargetParser which then makes it possible to query it
from llvm. Here is an example why this is handy:
https://github.com/llvm/llvm-project/pull/87939

show more ...

[RISCV] Support __builtin_cpu_is

We have defined `__riscv_cpu_model` variable in #101449. It contains
`mvendorid`, `marchid` and `mimpid` fields which are read via system
call `sys_riscv_hwprobe`.

[RISCV] Support __builtin_cpu_is

We have defined `__riscv_cpu_model` variable in #101449. It contains
`mvendorid`, `marchid` and `mimpid` fields which are read via system
call `sys_riscv_hwprobe`.

We can support `__builtin_cpu_is` via comparing values in compiler's
CPU definitions and `__riscv_cpu_model`.

This depends on #116202.

Reviewers: lenary, BeMg, kito-cheng, preames, lukel97

Reviewed By: lenary

Pull Request: https://github.com/llvm/llvm-project/pull/116231

show more ...

Revert "[RISCV] Add mvendorid/marchid/mimpid to CPU definitions (#116202)" chain

This reverts commit b36fcf4f493ad9d30455e178076d91be99f3a7d8.
This reverts commit c11b6b1b8af7454b35eef342162dc2cddf5

Revert "[RISCV] Add mvendorid/marchid/mimpid to CPU definitions (#116202)" chain

This reverts commit b36fcf4f493ad9d30455e178076d91be99f3a7d8.
This reverts commit c11b6b1b8af7454b35eef342162dc2cddf54b4de.
This reverts commit 775148f2367600f90d28684549865ee9ea2f11be.

multiple bot build breakages, e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/8076

show more ...

[RISCV] Support __builtin_cpu_is

We have defined `__riscv_cpu_model` variable in #101449. It contains
`mvendorid`, `marchid` and `mimpid` fields which are read via system
call `sys_riscv_hwprobe`.

[RISCV] Support __builtin_cpu_is

We have defined `__riscv_cpu_model` variable in #101449. It contains
`mvendorid`, `marchid` and `mimpid` fields which are read via system
call `sys_riscv_hwprobe`.

We can support `__builtin_cpu_is` via comparing values in compiler's
CPU definitions and `__riscv_cpu_model`.

This depends on #116202.

Reviewers: lenary, BeMg, kito-cheng, preames, lukel97

Reviewed By: lenary

Pull Request: https://github.com/llvm/llvm-project/pull/116231

show more ...

[Clang][RISCV] Support -fcf-protection=return for RISC-V (#112477)

Enables the support of `-fcf-protection=return` on RISC-V, which
requires Zicfiss. It also adds a string attribute "hw-shadow-stac

[Clang][RISCV] Support -fcf-protection=return for RISC-V (#112477)

Enables the support of `-fcf-protection=return` on RISC-V, which
requires Zicfiss. It also adds a string attribute "hw-shadow-stack"
to every function if the option is set on RISC-V

show more ...

[clang][RISCV] Introduce command line options for RISC-V Zicfilp CFI

This patch enables the following command line flags for RISC-V targets:

+ `-fcf-protection=branch` turns on forward-edge contr

[clang][RISCV] Introduce command line options for RISC-V Zicfilp CFI

This patch enables the following command line flags for RISC-V targets:

+ `-fcf-protection=branch` turns on forward-edge control-flow integrity conditioning
+ `-mcf-branch-label-scheme=unlabeled|func-sig` selects the label scheme used in the forward-edge CFI conditioning

show more ...

[RISCV] Implement validateGlobalRegisterVariable. (#109596)

Only allow GPR registers and verify the size is the same as XLen.

This fixes the crash seen in #109588 by making it a frontend error.

[RISCV] Implement validateGlobalRegisterVariable. (#109596)

Only allow GPR registers and verify the size is the same as XLen.

This fixes the crash seen in #109588 by making it a frontend error.

gcc does accept the code so we may need to consider if we can fix the
backend. Some other targets I tried appear to have similar issues so it
might not be straightforward to fix.

show more ...

[Clang][RISCV] Recognize unsupport target feature by supporting isValidFeatureName (#106495)

This patch makes unsupported target attributes emit a warning and ignore
the target attribute during sem

[Clang][RISCV] Recognize unsupport target feature by supporting isValidFeatureName (#106495)

This patch makes unsupported target attributes emit a warning and ignore
the target attribute during semantic checks. The changes include:

1. Adding the RISCVTargetInfo::isValidFeatureName function.
2. Rejecting non-full-arch strings in the handleFullArchString function.
3. Adding test cases to demonstrate the warning behavior.

show more ...

[RISCV] Support __builtin_cpu_init and __builtin_cpu_supports (#99700)

This implements the __builtin_cpu_init and __builtin_cpu_supports
builtin routines based on the compiler runtime changes in
h

[RISCV] Support __builtin_cpu_init and __builtin_cpu_supports (#99700)

This implements the __builtin_cpu_init and __builtin_cpu_supports
builtin routines based on the compiler runtime changes in
https://github.com/llvm/llvm-project/pull/85790.

This is inspired by https://github.com/llvm/llvm-project/pull/85786.
Major changes are a) a restriction in scope to only the builtins (which
have a much narrower user interface), and the avoidance of false
generality. This change deliberately only handles group 0 extensions
(which happen to be all defined ones today), and avoids the tblgen
changes from that review.

I don't have an environment in which I can actually test this, but @BeMg
has been kind enough to report that this appears to work as expected.

Before this can make it into a release, we need a change such as
https://github.com/llvm/llvm-project/pull/99958. The gcc docs claim that
cpu_support can be called by "normal" code without calling the cpu_init
routine because the init routine will have been called by a high
priority constructor. Our current compiler-rt mechanism does not do
this.

show more ...

[RISCV] Add -m[no-]scalar-strict-align and -m[no-]vector-strict-align. (#95024)

[C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (#89446)

These macros are used by STL implementations to support implementation
of std::hardware_destructive_interference_size and
std::hardware_constr

[C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (#89446)

These macros are used by STL implementations to support implementation
of std::hardware_destructive_interference_size and
std::hardware_constructive_interference_size

Fixes #60174

---------

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

show more ...

[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)

This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow

[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)

This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow us to generate part of RISCVISAInfo.cpp using tablegen.

show more ...

[RISCV] RISCV vector calling convention (1/2) (#77560)

[RISCV] RISCV vector calling convention (1/2)

This is the vector calling convention based on
https://github.com/riscv-non-isa/r

[RISCV] RISCV vector calling convention (1/2) (#77560)

[RISCV] RISCV vector calling convention (1/2)

This is the vector calling convention based on
https://github.com/riscv-non-isa/riscv-elf-psabi-doc,
the idea is to split between "scalar" callee-saved registers
and "vector" callee-saved registers. "scalar" ones remain the
original strategy, however, "vector" ones are handled together
with RVV objects.

The stack layout would be:

|--------------------------| <-- FP
| callee-allocated save |
| area for register varargs|
|--------------------------|
| callee-saved registers | <-- scalar callee-saved
| (scalar) |
|--------------------------|
| RVV alignment padding |
|--------------------------|
| callee-saved registers | <-- vector callee-saved
| (vector) |
|--------------------------|
| RVV objects |
|--------------------------|
| padding before RVV |
|--------------------------|
| scalar local variables |
|--------------------------| <-- BP
| variable size objects |
|--------------------------| <-- SP

Note: This patch doesn't contain "tuple" type, e.g. vint32m1x2.
It will be handled in https://github.com/riscv-non-isa/riscv-elf-psabi-doc (2/2).

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

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 ...

[RISCV] Remove experimental from Vector Crypto extensions (#74213)

The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be

[RISCV] Remove experimental from Vector Crypto extensions (#74213)

The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be
non-experimental, while leaving the C intrinsics as experimental since
the C intrinsics are not yet standardized.

Co-authored-by: Brandon Wu <brandon.wu@sifive.com>

show more ...

[RISCV] Support target attribute for function

The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35

This patch implements it by emitting .option arch during c

[RISCV] Support target attribute for function

The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35

This patch implements it by emitting .option arch during codegen.

Reviewed By: craig.topper

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

show more ...

[RISCV] Support predefined macro __riscv_misaligned_[fast,avoid]. (#65756)

RISC-V C API introduced predefined macro to achieve hints about
unaligned accesses ([pr]). This patch defines __riscv_misa

[RISCV] Support predefined macro __riscv_misaligned_[fast,avoid]. (#65756)

RISC-V C API introduced predefined macro to achieve hints about
unaligned accesses ([pr]). This patch defines __riscv_misaligned_fast
when using -mno-strict-align, otherwise, defines
__riscv_misaligned_avoid.

Note: This ignores __riscv_misaligned_slow which is also defined by
spec.

[pr]: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/40

show more ...

[RISCV][BF16] Enable __bf16 for riscv targets

The RISC-V psABI recently added __bf16 in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/367.
Now we can enable this new type in clang.

Revi

[RISCV][BF16] Enable __bf16 for riscv targets

The RISC-V psABI recently added __bf16 in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/367.
Now we can enable this new type in clang.

Reviewed By: craig.topper

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

show more ...

[RISCV] Enable strict fp for RISC-V in clang.

Reviewed By: craig.topper

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

[clang] Return `std::string_view` from `TargetInfo::getClobbers()`

Change the return type of `getClobbers` function from `const char*`
to `std::string_view`. Update the function usages in CodeGen mo

[clang] Return `std::string_view` from `TargetInfo::getClobbers()`

Change the return type of `getClobbers` function from `const char*`
to `std::string_view`. Update the function usages in CodeGen module.

The reasoning of these changes is to remove unsafe `const char*`
strings and prevent unnecessary allocations for constructing the
`std::string` in usages of `getClobbers()` function.

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

show more ...

[RISCV] Replace RISCV -> RISC-V in comments. NFC

To be consistent with RISC-V branding guidelines
https://riscv.org/about/risc-v-branding-guidelines/
Think we should be using RISC-V where possible.

[RISCV] Replace RISCV -> RISC-V in comments. NFC

To be consistent with RISC-V branding guidelines
https://riscv.org/about/risc-v-branding-guidelines/
Think we should be using RISC-V where possible.

More patches will follow.

Reviewed By: asb

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

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.