[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