[OE-core] [PATCH 0/6] Correct and improve the ARM tunings

[Adrian Bunk]

On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote:
> On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk <bunk at stusta.de> 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?

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