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

[Khem Raj]

On Wed, Nov 6, 2019 at 4:48 PM Alistair Francis <Alistair.Francis at wdc.com>
wrote:

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


We need to handle that but I think that should be in meta-riscv since I
think for Linux we should just stick to rv64gc ABI and something cross
distro agreed upon abi for riscv32 and bare metal is another story that’s
where probably we need to address the ABIs

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


This is fine to start with for now


>
> Alistair
>
> >
> > cu
> > Adrian
> >
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191106/25f965ed/attachment.html>