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

Andre McCurdy armccurdy at gmail.com
Wed Apr 3 19:29:29 UTC 2019


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).

> And that's only for the legacy 32bit platforms.
>
> armv8 already has 21 feature modifiers in gcc 9,
> and while not all 2^21 or 3^21[2] combinations are
> valid the old tune approach won't scale for that.
>
> > Cheers,
> >
> > Richard
>
> cu
> Adrian
>
> [1] https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-miscellaneous-changes
> [2] enable/disable/default
>
> --
>
>        "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
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


More information about the Openembedded-core mailing list