On Wed, Apr 3, 2019 at 1:24 PM Adrian Bunk <[email protected]> wrote: > On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote: > > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk <[email protected]> wrote: > > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote: > > > >... > > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t" > > > > which is the convention used throughout all the tune files. > > > >... > > > > > > Unfortunately this is not true. > > > > > > OE has both armv7a and armv7at tunes. > > > > > > There is no armv7a without Thumb support, > > > so no -march=armv7-at exists in gcc. > > > > > > Both armv7a and armv7at tunes pass the same march to gcc, > > > but [1] is not true: > > > Default to using the Thumb-2 instruction set for armv7a and above. > > > > > > The hardware supports Thumb-2 in any case, the actual difference between > > > the armv7a and armv7at OE tunes is whether OE tells the compiler to > > > generate ARM or Thumb-2 code. > > > > > > OE has both armv6 and armv6t tunes. > > > > > > There is no armv6 without Thumb support > > > so no -march=armv6t exists in gcc. > > > > > > Some v6 support only Thumb-1 and some v6 support also Thumb-2, > > > so what gcc does have is an -march=armv6t2. > > > But OE lacks tunes for that. > > > > > > For matching the gcc options it would be correct to remove all > > > armv6t and armv7at tunes that have no coresponding gcc options, > > > and add armv6t2 tunes. > > > > Aligning the tuning options exposed via the machine config files to > > those supported by gcc seems like a worthy goal... but would be a big > > upheaval at this point. > > > > Note that the problem isn't specific to ARM. There are similar issues > > for x86, but there we seem happy to provide a very minimal abstraction > > with no attempt to track gcc. e.g. "corei7" hasn't been a documented > > -march option since gcc 4.8 and we (somewhat arbitrarily) map it to > > -march=nehalem to hide that fact from end users. > > > > So the high level question seems to be: should DEFAULTTUNE even > > attempt to provide a full featured mapping to the options provided by > > gcc? Are we happy to expose a limited subset without a 1:1 mapping for > > the options we do expose (current ARM approach) or is it better for > > DEFAULTTUNE to hide away all the complexity of the options provided by > > gcc (current x86 approach). > > The current 32bit ARM[1] approach seems to be an attempt > of a 1:1 mapping. > > For ARMv8 it is already obvious that DEFAULTTUNE is not long-term > maintainable, and duplicating all the gcc rules regarding feature > flags[2] also sounds like a pointless exercise. > > What are actually the benefits of DEFAULTTUNE with all the tune files, > compared to just let the user provide a string that is passed to -march?
Restricting the user to a certain set of DEFAULTTUNE options means there will always be a valid mapping from DEFAULTTUNE to PACKAGE_EXTRA_ARCHS. If we let the user pass an arbitrary string to -march then we lose the ability to determine that (for example) it's safe for a "armv7athf-vfpv3" machine to pull from a "armv7athf-vfpv3d16" package feed. Whether or not anyone in the real world actually maintains a generic package feed and pulls from it from multiple machine specific builds (verses setting up separate package feeds for each DEFAULTTUNE they care about) would be an interesting question... > cu > Adrian > > [1] ARM <= v7, not the differing 32bit ABI of ARMv8 > [2] example: > '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. > > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
