> -----Original Message----- > From: Richard Purdie <[email protected]> > Sent: den 2 april 2019 22:27 > To: Peter Kjellerstedt <[email protected]>; openembedded- > [email protected] > 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
