[OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi Andre,

I believe I did say always present on armv8 and armv7, I did not mean before that.
Having separate tunes for thumb support was necessary on previous architectures where it was optional, but it persisted for architectures which made thumb mandatory.
I’m not even advocating removing the tune option for previous architectures that would normally not require it, but I believe we should get rid of it for new ARM architectures.

Cheers,
Herve

> On 13 Jun 2018, at 04:39, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
>> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
>>> On 6/12/18 10:49 AM, Herve Jourdain wrote:
>>> Hi,
>>> 
>>> So I agree with you about restricting to what gcc can support, that's actually my proposal (actually, probably a subset of what gcc can support).
>>> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, armv8.2-a, armv8.3-a, armv8.4-a.
>>> Then, you can add the supported options with a "+" after the architecture.
>>> Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', '+nofp'
>>> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', '+nofp'
>>> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>>> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>>> 
>>> As you can see, proposals for armv8-a, whether my previous one, the new one here, or even the one I have updated and used in production, just capture the existing complexity, and not add to it.
>>> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add more options down the line.
>> 
>> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we don't
>> necessarily define a tune that uses them -- if it's standard another layer
>> certainly could.)
>> 
>>> Regarding fpu, gcc supports the following for armv8: fp-armv8, neon-fp-armv8, and crypto-neon-fp-armv8.
>>> 
>>> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’.
>>> 
>>> I personally would like to keep tuning for a specific CPU as much as possible (again I'm working closely with various ARM-based SoCs, so my opinion might be tainted).
>> 
>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>> more reasonable to support all of this.. (maybe that is what needs to be done in
>> the future as well for other architectures.. focus on the 'gcc' behavior and
>> generate TUNE_FEATURES matching the compiler.)
>> 
>> I'd like Khem's opinion on how crazy of an idea that is.
>> 
>>> One thing that could be done to simplify things would be to just use the cpu, and add the options to it. Gcc supports adding options to the cpu.
>>> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
>>> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
>>> 
>>> That could simplify the tune settings, but would give less control than what we currently have.
>>> As you might have guessed, I do put a specific emphasis on the crypto option, and on the neon option, which are the most interesting for armv8 in my opinion.
>> 
>> In the past 'crypto' options have only been assembly.. if that's changed it has
>> definitely opened up a new facet in all of this work.
>> 
>>> Regarding thumb, always adding it to the tune without creating specific variants with or without thumb makes sense, since the tune is normally about the SoC capabilities, and arv7 and armv8 both support it.
>>> You can always select whether you want thumb or not by setting ARM_INSTRUCTION_SET appropriately at the distro level.
>> 
>> Yes, that might be needed now that thumb is theoretically always supposed to be
>> present.
> 
> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.
> 
> However the option has been unnecessarily propagated into tuning files
> for higher architecture levels where support for Thumb _is_ always
> present.