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

[Khem Raj]

> On Apr 1, 2016, at 3:03 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
> 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?

I would support the latter. Andre, since you have mentioned it earlier
would you mind opening a bugzilla entry for cleanup for 2.2 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160401/e53d009e/attachment-0002.sig>