This changes the save/restore procedures to save/restore registers one
by one - to match the stack alignment for the ILP32E/LP64E ABIs, rather
than the larger batches of the conventional ABIs. The implementations of
the save routines are not tail-shared, to reduce the number of
instructions. I think this also helps code size but I need to check this
again.
I would expect (but haven't measured) that the majority of functions
compiled for the ILP32E/LP64E ABIs will in fact use both callee-saved
registers, and therefore there are still savings to be had, but I think
those can come later, with more data (especially if those changes are
just to the instruction sequences we use to save the registers, rather
than the number and alignment of how this is done).
This is a potential break for all of the ILP32E/LP64E ABI - we may
instead have to teach the compiler to emit the CFI information correctly
for the grouping we already have implemented (because that grouping
matches GCC). It depends on how intentional we think the grouping is in
the original ILP32E/LP64E save/restore implementation was, and whether
we think we can fix that now.
Changes included:
- Adding CONSTRUCTOR_ATTRIBUTE so that the static data is setup early on
in process lifetime. This is required by gcc docs for
__builtin_cpu_supports which we hope to implement in terms of this.
- Move the length initialization outside of the #if defined(linux) block
so that the length field always reflects the size of the structures even
if non of the feature bits are non-zero.
- Change the __riscv_vendor_feature_bits.length field to match the
length of the actual structure.
Note: Copy from https://github.com/llvm/llvm-project/pull/99958
---------
Co-authored-by: Philip Reames <preames@rivosinc.com>
Base on https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74, this
patch defines the `__riscv_feature_bits` and
`__riscv_vendor_feature_bits` structures to store the enabled feature
bits at runtime.
It also introduces the `__init_riscv_feature_bits` function to update
these structures based on the platform query mechanism.
Additionally, the groupid/bitmask definitions from
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74 are declared
and used to update the `__riscv_feature_bits` and
`__riscv_vendor_feature_bits` structures.
---------
Co-authored-by: Kito Cheng <kito.cheng@gmail.com>
When compiling for the ILP32E/LP64E ABIs, even on a RISC-V machine with
`i`, we should be using the ILP32E/LP64E save/restore routines, so use
the right preprocessor macro.
Zfinx extension also provide floating point environment like F extension, so
enable that on `__fe_getround` and `__fe_raise_inexact` too.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D154570
The RISC-V implementations of the `__mulsi3`, `__muldi3` builtins were
conditionally compiling the actual function definitions depending on whether
the M extension was present or not. This caused Compiler-RT testing failures
for RISC-V targets with the M extension, as when these sources were included
the `librt_has_mul*i3` features were still being defined. These `librt_has_*`
definitions are used to conditionally run the respective tests. Since the
actual functions were not being compiled-in, the generic test for `__muldi3`
would fail. This patch makes these implementations follow the normal
Compiler-RT convention of always including the definition, and conditionally
running the respective tests by using the lit conditional
`REQUIRES: librt_has_*`.
Since the `mulsi3_test.c` wasn't actually RISC-V-specific, this patch also
moves it out of the `riscv` directory. It now only depends on
`librt_has_mulsi3` to run.
Differential Revision: https://reviews.llvm.org/D86457
Provides an assembly implementation of muldi3 for RISC-V, to solve bug 43388.
Since the implementation is the same as for mulsi3, that code was moved to
`riscv/int_mul_impl.inc` and is now reused by both `mulsi3.S` and `muldi3.S`.
Differential Revision: https://reviews.llvm.org/D80465
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
