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

[Peter Kjellerstedt]

> -----Original Message-----
> From: Richard Purdie <richard.purdie at linuxfoundation.org>
> Sent: den 2 april 2019 22:27
> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>; openembedded-
> core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
> 
> On Tue, 2019-04-02 at 21:30 +0200, Peter Kjellerstedt wrote:
> > These patches are intended to improve the ARM tunings and came about
> > after I had to study the tune files a lot more than I first had
> > anticipated...
> >
> > The first patch (arch-armv8a.inc: Correct
> > PACKAGE_EXTRA_ARCHS_tune-armv8a-*) avoids odd architectures such as
> > "crc" and "crypto" to be included in PACKAGE_EXTRA_ARCHS.
> >
> > The following three patches (where i have sent the latter two to the
> > list before) restores the "armv*" features to TUNE_FEATURES for all
> > ARM based SoCs as it does not make sense to remove them from the SoC
> > specific tune files just to determine whether -mcpu or -march shall
> > be used. This is because the SoCs still support the armv* features
> > specified in their TUNE_FEATURES even if they also have more specific
> > SoC tunings.
> 
> It depends how you view TUNE_FEATURES and what the presence of things
> there is defined to mean.

The assumption I made was that the features listed in TUNE_FEATURES 
matches what features the compiler/linker will make use of when 
building the code and something that can be checked by, e.g., recipes 
to enable/disable functionality to match this. There are examples of 
this in the recipes in OE-Core, e.g., where TUNE_FEATURES is checked 
to determine what options to pass to configure.

E.g., with DEFAULTTUNE set to "arm926ejs", TUNE_FEATURES expands to 
"arm armv5 thumb dsp arm926ejs" (with Thud and older, or with my 
patches applied). To me this means that I can assume that I can use 
anything that is specific to either of those features when I decide 
what to build. And although arm926ejs implies armv5, having the 
latter as a separate feature makes it possible to write a generic 
test for armv5 without having to know the exact SoC and what it 
supports.

> "armv4t" is defined in the arm tune files to mean "add -march=armv4t"
> which is the convention used throughout all the tune files.

I fail to see where it says that the "armv*" features of TUNE_FEATUES 
are to be used to set -march and nothing else. That seems like a very 
odd implication of one of the many features specified in TUNE_FEATURES.

However, with my patches applied, the "armv*" features still says to 
set -march, unless there is also a more specific tune feature, e.g., 
"arm926ejs", which means -mcpu will be used instead. I don't think 
deciding between -mcpu and -march should be based on the existence or 
non-existence of a given feature in TUNE_FEATURES, but rather on the 
context. This also matches how the TUNE_FEATURES_tune-arm* variables 
are being defined with more specific variables such as 
TUNE_FEATURES_tune-arm926ejs being defined based on more generic 
variables (TUNE_FEATURES_tune-armv5te in this case) and then adding 
the more specific feature(s).

> I'm still not convinced this part of your changes improves the
> situation as it then breaks and confuses that situation.

According to my view there is less confusion now. TUNE_FEATURES yet 
again describes the features that are supported.

> I'm also worried you're wanting this as you have code elsewhere which
> is using "armvX" there to mean something else?

Actually we're not using any such tests. I did the initial rework 
based on the notion that the change that had gone into the tuning 
files felt wrong, tearing out the structure that was previously 
there in the definitions of the TUNE_FEATURES_tune-arm* variables, 
and how it had messed up my view of what the features in 
TUNE_FEATURES are supposed to mean. And after having studied those 
files a lot more, that initial notion still holds true for me.

> Cheers,
> 
> Richard

//Peter