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

Richard Purdie richard.purdie at linuxfoundation.org
Sat Nov 9 22:05:22 UTC 2019


On Sat, 2019-11-09 at 22:30 +0200, Adrian Bunk wrote:
> On Fri, Nov 08, 2019 at 11:07:04PM +0000, Richard Purdie wrote:
> > On Fri, 2019-11-08 at 22:24 +0200, Adrian Bunk wrote:
> > > Especially when looking at the arm64 situation I am wondering
> > > whether the best option might be to throw away the tunes mess and
> > > let
> > > the user write the compiler options directly.
> > 
> > OE once did that. I think anyone who lived through it would say
> > that
> > the current situation *is* an improvement over a free-for-all.
> > 
> > This is mainly as at least we're now consistent whereas before the
> > same
> > thing had different names in each BSP.
> 
> The BSPs should not invent names for anything, all a BSP should do
> would be to set some kind of
>   TARGET_CFLAGS += "-mcpu=cortex-a53+crc+crypto+sm4+nosimd"

What is the name of the package feed these binaries would go into?

> > I don't know what the answer is but I don't want to go back to
> > that!
> 
> As of gcc 9 there are for arm64[1]:
> 
> 6 -march= architecture levels (8.0 to 8.5)
> 35 -mtune= tune options
> 22 modifiers for -march= and -mtune=
> 3 different ABIs (aarch64, aarch64-ilp32, armv7)
> 
> Even ignoring the tunes you already have
>   6 * 2^22
> different architecture+modifier combinations.
> 
> Not all combinations are valid, but another can of worms are the
> definitions what is valid and what is default amd what gets
> indirectly
> enabled, e.g.
>   fp16fml
>     Enable FP16 fmla extension. This also enables FP16 extensions
> and 
>     floating-point instructions. This option is enabled by default
> for 
>     -march=armv8.4-a. Use of this option with architectures prior to 
>     Armv8.2-A is not supported.
> 
> It can be recursive:
>   Feature crypto implies aes, sha2, and simd, which implies fp. 
>   Conversely, nofp implies nosimd, which implies nocrypto, noaes and
> nosha2. 

I'd advocate that we add the combinations which people need and use.
The tune structure doesn't require every combination be there.

Cheers,

Richard





More information about the Openembedded-core mailing list