[OE-core] [PATCH v2 1/4] arch-armv8a.inc: add tune include for armv8

[Mark Hatle]

On 6/12/18 12:59 AM, Nicolas Dechesne wrote:
> On Sat, Jun 9, 2018 at 8:26 AM, Randy Li <ayaka at soulik.info> wrote:
>> There are some addtional instructions apart from bare armv8,
>> also there is armv8.1, armv8.2.
>>
>> Most the processor would support crc, except X-gene 1.
> 
> the commit message doesn't really explain what is going on in this patch..
> 
>>
>> Signed-off-by: Randy Li <ayaka at soulik.info>
>> ---
>>  meta/conf/machine/include/arm/arch-armv8.inc  |  1 -
>>  meta/conf/machine/include/arm/arch-armv8a.inc | 22 ++++++++++++++++++++++
>>  2 files changed, 22 insertions(+), 1 deletion(-)
>>  delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
> ^^ this file is used by probably any armv8 machine out there, even
> inside oe-core:
> 
> $ git grep "arch-armv8\.inc"
> include/tune-thunderx.inc:require conf/machine/include/arm/arch-armv8.inc
> qemuarm64.conf:require conf/machine/include/arm/arch-armv8.inc
> 
> so this change would break many things. and it's used in many BSP layers.
> 
>>  create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
>>
>> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc b/meta/conf/machine/include/arm/arch-armv8.inc
>> deleted file mode 100644
>> index 5e832fae6d..0000000000
>> --- a/meta/conf/machine/include/arm/arch-armv8.inc
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -require conf/machine/include/arm/arch-arm64.inc
>> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc b/meta/conf/machine/include/arm/arch-armv8a.inc
>> new file mode 100644
>> index 0000000000..b8b9e44c54
>> --- /dev/null
>> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
>> @@ -0,0 +1,22 @@
>> +DEFAULTTUNE ?= "armv8a-crc"
> 
> even without taking into consideration that this is changing all
> default configs for arm64.. which should for sure be discussed and
> agreed upon... the crc and crypto flags you are adding here, are not
> defined anywhere.
> 
> please review how the armv7 variants were designed/introduced, and try
> to mimic that for armv8 if you think it's needed.
> 
>> +
>> +TUNEVALID[armv8] = "Enable instructions for ARMv8-a"
>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', ' -march=armv8-a', '', d)}"
>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', 'armv8a:', '' ,d)}"
>> +
>> +require conf/machine/include/arm/arch-arm64.inc
>> +
>> +# Little Endian base configs
>> +AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
>> +ARMPKGARCH_tune-armv8a                    ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crc                ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crypto             ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crc-crypto         ?= "armv8a"

To add to Nicolas's comment.  Are any of the variants mentioned above, have the
additional instructions generated by the toolchain?  Or are they purely assembly
level functionality?

Generally we defined tunes as something that can be generated by the compiler.
For things that are assembly driven, a new tune is rarely required, but instead
the developer of the component should either do run-time switching of assembly
functions, or it becomes board/distribution specific.  (There are always
exceptions to that, but that policy helps simplify the tunes to things that matter.)

>> +TUNE_FEATURES_tune-armv8a                  = "armv8a simd"
>> +TUNE_FEATURES_tune-armv8a-crc              = "${ARMPKGARCH_tune-armv8a} crc"
>> +TUNE_FEATURES_tune-armv8a-crypto           = "${TUNE_FEATURES_tune-armv8a} crypto"
>> +TUNE_FEATURES_tune-armv8a-crc-crypto       = "${TUNE_FEATURES_tune-armv8a-crc} crypto"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a            = "aarch64 armv8a simd"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc        = "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto     = "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
>> --
>> 2.14.3
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core