On Thu, 2 May 2019 at 22:35, Jim Wilson <j...@sifive.com> wrote: > > 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. >
A future version of the D language adds a new feature to cover this, __traits(getTargetInfo,"key"). https://dlang.org/spec/traits.html#getTargetInfo I have a slight inclination to push the information there instead of adding additional RISCV_* version conditions, particularly as the result returned can be any kind of value, which has a slight leverage over version conditions which are just boolean true/false. -- Iain