[OE-core] [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Andre McCurdy]

On Fri, Apr 1, 2016 at 12:13 PM, Otavio Salvador
<otavio.salvador at ossystems.com.br> wrote:
> Hello folks,
>
> On Wed, Mar 30, 2016 at 8:59 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
>> On Wed, Mar 30, 2016 at 3:46 PM, Phil Blundell <pb at pbcl.net> wrote:
>>> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
>>>> Either way it shouldn't be a concern for the CPU tuning files.
>>>> Building Thumb2 for an armv8a CPU is really just an extension of
>>>> "optimise for size" and we don't include -Os, -O2, etc options in the
>>>> CPU tuning files.
>>>
>>> Yes, agreed.  In principle there's no reason that the compiler couldn't
>>> choose between A32 and T32 instruction sets dynamically for each
>>> compilation unit (or each function) according to which it thinks would
>>> give the better result.  And from the user's point of view, the outcome
>>> should be equivalent apart from minor performance differences.
>>>
>>>> >> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>>>> >> hardcoded assumptions won't work.
>>>
>>>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
>>>> ARMv8-A mentions:
>>>>
>>>> "Both floating-point and NEON are required in all standard ARMv8
>>>> implementations. However, implementations targeting specialized
>>>> markets may support the following combinations:
>>>>
>>>>  - No NEON or floating-point.
>>>>  - Full floating-point and SIMD support with exception trapping.
>>>>  - Full floating-point and SIMD support without exception trapping.
>>>
>>> Is there any evidence that anyone is actually building ARMv8-A (as
>>> opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
>>> fairly clear indication that such cores do exist and are likely to be
>>> used with OE, I think we should not complicate the tuning files with
>>> support for such things.  Anybody who wants them can always add
>>> appropriate tunes later, either in oe-core or in their own layer.
>>
>> I can't find any evidence of real ARMv8-A cores without NEON or VFP,
>> so if any "new approach" to ARM CPU tuning files is limited to armv8a
>> then hardcoding support for NEON and VFP is probably going to work out
>> OK (at least until someone wants support for the half-precision
>> floating point extensions added in ARMv8.2-A).
>>
>> Personally though, I'd like to see a comprehensive cleanup and
>> restructuring which could be applied to all ARM tuning files,
>> including armv7a where NEON certainly is optional in the real world.
>
> Could you, Phil and Khem summarize the remarks in a succinct way? To
> be honest I am a little lost on what changes you all are expecting on
> top of the last patch version.

I think the last comment from Richard was:

"I'm planning to drop the patch triggering this from -next and
defer it until 2.2. The discussions can happen in the meantime to get a
patchset we're all happy with."

So I don't think anything is expected for 2.1.

The floor is still open for discussion for 2.2. One initial question
seems to be whether we're aiming for a point solution for armv8a or a
wider ranging cleanup?

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750