Enforce DEFAULTTUNE across all platforms/architectures/BSPs
Description
Environment
relates to
Activity
Jan-Simon Moeller May 25, 2017 at 8:32 PM
Deployed.
Jan-Simon Moeller April 25, 2017 at 11:45 AMEdited
Update:
As more discussions and emails come-in on the ML, it becomes clear that:
We will need a medium and a high compiler-setting for ARM 32bit.
This may correspond with the discussed distribution profiles (headless, graphical) that are being discussed. Aka headless = medium , graphical = high
The high profile will include the armv7ve tuning (virtualization extensions) resulting in the requirement of >= cortex-15
The medium profile will include the armv7-a tuning (no virtualization extensions) resulting in the requirement of >= cortex-a8
E.g.:
High compiler setting: -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard
Medium compiler setting: -march=armv7-a -mfpu=neon -mfloat-abi=hard
The high profile is similar to the capabilities for aarch64 in 32bit mode
The medium profile is very compatible to a broad range of ARM 32bit cores
We will have one tuning for AARCH64
this is "-march=armv8-a"
As a distro, we will not apply tunes to specific core types (cortex-a57.cortex-a53).
This can be done in your own build w/o issues (we will document)
We will have one tuning for qemux86_64/intel-core-i7
Which exact tuning is still to be decided (have to try out qemu modifications)
likely: -m64 -march=corei7 -mfpmath=sse -msse4.2
Jan-Simon Moeller April 13, 2017 at 6:08 PMEdited
Sure, things change over time, but a reasonable choice will last for quite some time.
IMHO even if we deprecate porter after DD, the 'common' set of flags will stay as long as we use ARM 32bit.
To come to a good conclusion we should answer these:
**
do we need virtualization extensions on ARM 32bit / armv7-a ?
do we need vfpv4 optimizations ?
are there reasons to exclude vfpv4 ?
what CPU's do we expect in the headless profile (cortex-a8 / a9 / a15 / ?? )
Once we have that, the choice can be made.
Stephane Desneux April 13, 2017 at 4:21 PM
Thx Jan-Simon for this summary.
My $0.02: the definitions will probably change from time to time. For example, Porter board will not be officially supported after DD so that may lead to some adjustments in the "ARM 32bits High profile". The same could occur if we add a new board.
AGL should as 'distro' enforce a common set of compiler tune flags instead of letting each BSP choose its own. This will reduce the number of BSP's needed to compile applications down to:
i586 (needed?)
x86_64
arm32 (e.g. vfpv4/neon + thumb2)
arm64 (e.g. ??)
No BSP should override the DISTRO settings (?= or ??=).
Outcome:
just one BSP needed for arm32 , arm64, x86 .