On Wed, May 1, 2019 at 6:14 PM Maciej Rozycki <ma...@wdc.com> wrote:
> within inline assembly, to access IEEE exception flags. The use of
> these instructions is not allowed when building for a soft-float ABI.
Technically it is an architecture issue not an ABI issue. If you
compile for -march=rv32imac -mabi=ilp32 then you can't use FP
instructions. If you compile for -march=rv32imafc -mabi=ilp32 then
you can use FP instructions, but we don't use FP regs for argument
passing. This is similar to the distinction that ARM makes between
the soft and softfp ABIs. The RISC-V newlib port for instance checks
__riscv_flen to decide whether to use FP instructions. The predefined
macro __riscv_flen is set to 0 if the target architecture doesn't have
FP registers. So the choice of using FP instructions depends on the
target architecture, not the target ABI.
I see that gcc/config/riscv/riscv-d.c has
if (TARGET_HARD_FLOAT)
d_add_builtin_version ("D_HardFloat");
else
d_add_builtin_version ("D_SoftFloat");
so the patch looks OK, because this is checking the architecture not the ABI.
But the arm/arm-d.c file is defining 3 ARM_* macros for FP support,
and long term we might need something similar in the RISC-V D port for
full RISC-V support. Through for RISC-V it is probably better to have
separate macros for architecture FP support and ABI FP support, each
of which can have 3 values, because you can have for instance an arch
with 64-bit FP support, but an ABI with only 32-bit FP support, and so
worst case we might need to track the arch/abi FP support separately.
This is how it works in the C front end. We have __riscv_flen which
can be 0, 4, or 8 and which indicates the hardware FP register size in
bytes. And we have __riscv_float_abi_soft, __riscv_float_abi_single,
and __riscv_float_abi_double, only one of which is defined, which
indicates the max size of arguments that can be passed in FP
registers.
Jim
