[OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float

Alistair Francis Alistair.Francis at wdc.com
Wed Nov 6 22:43:38 UTC 2019


On Thu, 2019-11-07 at 00:12 +0200, Adrian Bunk wrote:
> On Wed, Nov 06, 2019 at 10:18:18AM -0800, Alistair Francis wrote:
> > ...
> > +TUNE_CCARGS_riscv64 .= "${@bb.utils.contains('TUNE_FEATURES',
> > 'riscv64-f', ' -mabi=lp64d', ' -mabi=lp64', d)}"
> > +TUNE_CCARGS_riscv32 .= "${@bb.utils.contains('TUNE_FEATURES',
> > 'riscv32-f', ' -mabi=ilp32f', ' -mabi=ilp32', d)}"
> > ...
> 
> That looks wrong, what would you put in TUNE_FEATURES
> for -mabi=lp64f when -mabi=lp64d is called riscv64-f?

I am just going to add riscv32nf and riscv64nf. This will specify
-mabi=ilp32 and -mabi=lp64 accordingly. I won't change the default
riscv32 and riscv64. We can then deal with the single and double float
at a later point.

> 
> Also note that this is only the floating point calling convention,
> whether the compiler emits floating point instructions is defined
> by -march.

-march is another can of worms that I was trying to avoid. I don't have
a good way of handling the ISA strings at the moment without some crazy
number of tune options.

> 
> It would be good if this would start with a plan how to handle
> all possible combination of RISC-V ISA extensions, ideally better
> than the arm mess.

Agreed. I am just going to change this to add a no float option as that
fixes a large number of 32-bit link failures (seen in U-Boot, OpenSBI
and SDKs) and we can re-evaluate a longer term march fix.

Alistair

> 
> cu
> Adrian
> 


More information about the Openembedded-core mailing list