[OE-core] [PATCHv2][master] arch-armv8a.inc: Add tune for 32-bit ARMv8a

[Khem Raj]

On Sat, Mar 12, 2016 at 10:06 PM, Otavio Salvador
<otavio.salvador at ossystems.com.br> wrote:
> On Sat, Mar 12, 2016 at 10:23 AM, Khem Raj <raj.khem at gmail.com> wrote:
>> On Sat, Mar 12, 2016 at 8:02 PM, Otavio Salvador
>> <otavio.salvador at ossystems.com.br> wrote:
>>> On Sat, Mar 12, 2016 at 8:57 AM, Khem Raj <raj.khem at gmail.com> wrote:
>>>> On Sat, Mar 12, 2016 at 7:41 PM, Otavio Salvador
>>>> <otavio.salvador at ossystems.com.br> wrote:
>>>>> On Fri, Mar 11, 2016 at 9:17 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>>>>
>>>>>>> On Mar 12, 2016, at 12:58 AM, Daniel Dragomir <daniel.dragomir at windriver.com> wrote:
>>>>>>>
>>>>>>> This patch adds tunes for 32-bit armv8a platforms. The user can select
>>>>>>> little or big endian, hard or soft float, the vector floating-point
>>>>>>> instruction set: vfpv4 or fp-armv8 and the thumb, neon, crc and crypto
>>>>>>> extensions.
>>>>>>
>>>>>> This does not feel right to me. Look at how thunderX looks like
>>>>>> ARMv8 is the time to fix this tune explodes on arm, this patch is not helping
>>>>>> it.
>>>>>>
>>>>>> Do we need the hf/neon/vfp/thumb2 variants?
>>>>>
>>>>> Do you mean we ought to use hf+neon+thumb2+fp-armv8 for everyone and
>>>>> just have optional features in and out?
>>>>
>>>> something like that yes. Just aarch64 and aarch32 make it simple as that
>>>
>>> ARMv8.1a has different semantics, how does we handle this?
>>
>> question is do we need to handle this with tunes at all ?
>> what advantages are we looking for.
>
> I don't know but this was my main design doubt.
>
> To be honest, I think hf, neon, thumb2 and fp-armv8 can be default.
> Crypto and crc seem to be optional and need to be enabled if the core
> offers it. But those are required for ARMv8.1 SoCs ... AFAIK.

exactly, so lets see if crypto and crc can actually we offerred
differently via CCARGS instead