[OE-core] [RFC PATCH 2/3] conf/machine: Overhaul tune include files

Koen Kooi koen at dominion.thruhere.net
Mon Jul 11 17:04:15 UTC 2011


Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:

> On Mon, 2011-07-11 at 18:34 +0200, Koen Kooi wrote:
>> Op 11 jul 2011, om 17:57 heeft Richard Purdie het volgende geschreven:
>> 
>>> There is currently considerable confusion over how the tune files
>>> operate and hwo these interact with the rest of the build system.
>>> 
>>> This update/overhaul changes things so the tune files are primarily
>>> responsible for setting:
>>> 
>>> TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value
>>> that represents the architecture we're targetting.
>>> 
>>> TUNE_PKGARCH - The value that represents the tune configuration that
>>> this set of tune parameters results in.
>>> 
>>> The tune files continue to be responsible for setting the compiler
>>> flags as previously.
>>> 
>>> To determine the values for these fields, the tune code looks at
>>> the values set in TUNE_FEATURES. Possible values that can be included
>>> in this variable for a given tune file are shown in the TUNEVALID
>>> variable.
>>> 
>>> This code allows several significant improvements:
>>> 
>>> 1) The core can now always determine the target architecture value,
>>> even when TARGET_ARCH needs to be reset to something different.
>>> 
>>> 2) The tune code can allow for the definition of multilib configurations
>>> which can be enabled in the TUNE_FEATURES variable by the multilib class.
>>> 
>>> 3) Distros can easily configure/override specific tunable values
>>> that they're specifically interested in.
>>> 
>>> 4) Several versions of partial and buggy architecture support can be
>>> rolled into one good implementation (e.g. the arm endianness support).
>>> 
>>> Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
>>> ---
>>> meta-yocto/conf/machine/beagleboard.conf         |    1 -
>>> meta/conf/bitbake.conf                           |   11 +++++++----
>>> meta/conf/machine/include/tune-arm1136jf-s.inc   |    2 ++
>>> meta/conf/machine/include/tune-arm920t.inc       |    2 ++
>>> meta/conf/machine/include/tune-arm926ejs.inc     |    2 ++
>>> meta/conf/machine/include/tune-arm9tdmi.inc      |    2 ++
>>> meta/conf/machine/include/tune-armv7.inc         |   16 ++++++++++++----
>>> meta/conf/machine/include/tune-atom.inc          |    8 ++++++--
>>> meta/conf/machine/include/tune-cortexa8.inc      |   10 +++++++---
>>> meta/conf/machine/include/tune-strongarm1100.inc |    2 ++
>>> meta/conf/machine/include/tune-thumb.inc         |   22 ++++------------------
>>> meta/conf/machine/qemux86.conf                   |    3 ++-
>>> 12 files changed, 48 insertions(+), 33 deletions(-)
>> 
>>> diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
>>> index 979d6fe..6f7062f 100644
>>> --- a/meta/conf/machine/include/tune-armv7.inc
>>> +++ b/meta/conf/machine/include/tune-armv7.inc
>>> @@ -1,7 +1,15 @@
>>> +require conf/machine/include/arch-arm.inc
>> 
>> Where does that file live?
> 
> Oops, sorry, those dropped out the patchset as I was cleaning it up. I
> makes a lot more sense with these. They are:
> 
> diff --git a/meta/conf/machine/include/arch-arm.inc b/meta/conf/machine/include/arch-arm.inc
> new file mode 100644
> index 0000000..bf2df5f
> --- a/dev/null
> +++ b/meta/conf/machine/include/arch-arm.inc
> @@ -0,0 +1,4 @@
> +TUNEVALID += "bigendian"
> +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm" ,d)}"
> +
> +ENDSUFX = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "" ,d)}"
> diff --git a/meta/conf/machine/include/arch-ia32.inc b/meta/conf/machine/include/arch-ia32.inc
> new file mode 100644
> index 0000000..8d3f678
> --- a/dev/null
> +++ b/meta/conf/machine/include/arch-ia32.inc
> @@ -0,0 +1,17 @@
> +TUNEVALID += "m64"
> +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "m64", "x86_64", "i586" ,d)}"
> +
> +TUNEVALID += "ml-lib32"
> +TUNE_ARCH_ml-tune-lib32 = "i586"
> +base_libdir_ml-tune-lib32 = "${base_prefix}/lib32"
> +libdir_ml-tune-lib32 = "${exec_prefix}/lib32"
> +TUNEOVERRIDES += "${@bb.utils.contains("TUNE_FEATURES", "ml-lib32", ":ml-tune-lib32", "", d)}"
> +
> +TUNEVALID += "ml-lib64"
> +TUNE_ARCH_ml-tune-lib64 = "x86_64"
> +base_libdir_ml-tune-lib64 = "${base_prefix}/lib64"
> +libdir_ml-tune-lib64 = "${exec_prefix}/lib64"
> +TUNEOVERRIDES += "${bb.utils.contains("TUNE_FEATURES", "ml-lib64", ":ml-tune-lib64", "", d)}"
> +
> +OVERRIDES .= "${TUNEOVERRIDES}"
> +
> --
> cgit v0.8.3.3-89-gbf82
> 
>>> +TUNE_PKGARCH = "armv7"
>>> +TUNE_FEATURES_tune-armv7 ??= "hard-fpu"
>>> +
>>> # valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'
>>> # valid option for -mtune: `cortex-a8', `cortex-r4', `cortex-m3', `cortex-m1'
>>> # This will NOT compile programs in 'ARM' mode, which is what you really want
>>> -TARGET_CC_ARCH = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
>>> -FEED_ARCH = "armv7"
>>> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
>>> -BASE_PACKAGE_ARCH = "armv7"
>>> +TARGET_CC_ARCH += "-march=armv7"
>>> +TARGET_CC_ARCH += "-mfpu=vfp -mfloat-abi=softfp"
>>> +
>>> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "hard-fpu", "hard", "soft" ,d)}"
>> 
>> So the above takes care of the softfp calling conventions with hardware support or not, this doesn't take care of the hardfp calling conventions (mfloat-abi=hard)
>> 
>>> +PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX}"
>> 
>>> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
>>> index a5b982a..74c1e9e 100644
>>> --- a/meta/conf/machine/include/tune-cortexa8.inc
>>> +++ b/meta/conf/machine/include/tune-cortexa8.inc
>>> @@ -1,3 +1,8 @@
>>> +require conf/machine/include/arch-arm.inc
>>> +
>>> +TUNE_PKGARCH = "armv7a"
>>> +TUNE_FEATURES_tune-armv7a ??= "hard-fpu"
>>> +
>>> # Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3]
>>> # [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
>>> # [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html 
>>> @@ -8,6 +13,5 @@ TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>> 
>> And here you set mfpu=neon, while it's optional in both the cortex-a8
>> and armv7a standards. It also shows that we're messing with hardware
>> option (neon, vfp) and software option (softp) in one line. 
> 
> These need splitting off into different options. The info you've added
> below gives me a better idea of how to do that.

It's a mess and seems to be specific to arm, although ppc-spe and mips have similar issues.

>>> # Other potentially useful options
>>> #-ftree-vectorize -ffast-math -fno-omit-frame-pointer
>>> 
>>> -FEED_ARCH = "armv7a"
>>> -BASE_PACKAGE_ARCH = "armv7a"
>>> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
>>> +PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX} armv7a${ENDSUFX}"
>> 
>> Taking armv7a as an example with my angstrom hat on I need the following knobs:
>> 
>> 1) softp or hardfp calling conventions, resulting in a different package arch (e.g. armv7a vs armv7ahf) (link incompatible)
>> 2) neon or not, resulting in a different packagearch (e.g armv7a vs armv7a-vfponly) (link compatible)
>> 3) Thumb2 or arm mode, no direct need for different packagearch, they are compatible
>> 4) use FPU fw or not (TARGET_PFU) (slightly different from 2.)
>> 
>> Do you have any examples on how the package arch will look with this patchset?
> 
> I added in code to differentiate between big and little endian. We can
> add in code to add extra options, e.g. in the tune-armv7 case:
> 
> 
> TARGET_CC_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}"
> 
> PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"

And SUFX2 being 'hf' or '', right? If so, the proposal looks good to me, but I need to digest it some more.



More information about the Openembedded-core mailing list