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: > > 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 -- _______________________________________________ Openembedded-core mailing list Openembeddedfirstname.lastname@example.org http://lists.openembedded.org/mailman/listinfo/openembedded-core