Re: Tune files and knobs to turn

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2011-06-24 at 13:54 +0200, Koen Kooi wrote:
> We discussed tune files a bit during last nights TSC meeting and Khem
> had expressed the need before, so I'd like to get this discussion
> started by using armv7a as an example.
> 
> For armv7a capable cores we have the following hardware features:
> 
> * armv7a instruction set
> * thumb1 instruction set
> * thumb2 instruction set
> * VFP coprocessor
> * optional NEON coprocessor
> 
> For the ABI we can choose the following:
> 
> * softtp without hw support (e.g. no VFP instructions emitted, slow)
> * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast)
> * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw, incompatible with everything else
> 
> And the extra knobs:
> 
> * pure thumb1, no arm instructions (limited use)
> * thumb1/arm interworking
> * pure thumb2,  no arm instructions
> * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage)
> 
> In OE .dev we have the following vars:
> 
> TARGET_FPU: switches between hw float and sw float, no reflection in package arch
> ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or 'armv7a-hardfp' as package arch
> ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch
> THUMB_INTERWORK: turns on interworking, no reflection in package arch

I suspect having a variable per tune feature is going to be a recipe for
disaster. Selecting the tune options is something a machine is likely
going to want a good default of but some distros are going to want to
take control over in some cases too.

Given the n^2 problem we have with scale it starts to look like we'd
need something like TUNE_FEATURES which I don't feel brilliant about but
it likely could work well.

I'd also like to look at this from the other direction. What information
do we need from the tune config? Its one thing to set the controls but
we also need to consider what uses the end result and how. Currently the
tune files should really be responsible for:

TARGET_ARCH
TARGET_FPU
TARGET_CC_ARCH
PACKAGE_ARCH
BASE_PACKAGE_ARCH
PACKAGE_EXTRA_ARCHS
FEED_ARCH

of which there is some duplication of data. Also, the distro config
typically sets some of this. What we really need is the following:

* Overall compiler architecture
* Extra libc config data (softfloat?)
* Compiler optimisation flags
* Name of the package "architecture" to use for the config
* List of compatible package "architectures"

These map to:

* TARGET_ARCH
* TARGET_FPU
* TARGET_CC_ARCH
* BASE_PACKAGE_ARCH
* PACKAGE_EXTRA_ARCHS

but we do have issues of these names needing to be overridden so putting
then in some TUNE* namespace variables initially would help clean up the
core significantly.

Adding multlilib into the mix doesn't actually make the problem that
much more complex if we followed the simple rule of making the tune
config name an override. This would make the tune files follow the form:

TARGET_CC_ARCH_tune-armv7a = "xxx"
BASE_PACKAGE_ARCH_tune-armv7a = "xxx"

and then we'd add tune-xxx to OVERRIDES to select a given tuning for a
given multlilib.

I'm continuing to give this some thought but those are the ideas off the
top of my head...

Cheers,

Richard