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

[Richard Purdie]

On Sat, 2016-03-12 at 09:02 -0300, Otavio Salvador 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?

I do think Khem has a point here, there are way too many tunes in this
class and I've very much doubt they all make sense, there are likely
only a handful of key ones and it would be ideal just to filter the
class down to those.

The trouble I face is I don't really know all the details of armv8 so
I'm reliant on others with more knowledge of which ones make sense to
make the call...

Cheers,

Richard