[OE-core] [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Khem Raj]

On 14-08-25 14:12:07, Mark Hatle wrote:
> On 8/22/14, 5:26 PM, Martin Jansa wrote:
> >On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
> >>On Fri, 22 Aug 2014 23:46:26 +0200
> >>Martin Jansa <martin.jansa at gmail.com> wrote:
> >>
> >>>changing
> >>>default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while
> >>>still building with -marm doesn't make much sense to me and is only
> >>>confusing.
> >>
> >>I think the distinction is that if you use armv7at-neon, you *can* build
> >>specific packages with thumb. Mostly, I guess, I don't think it makes sense
> >>to use a tuning that specifically states that it can't run thumb code for
> >>processors which can. Although... May not be an important distinction, really,
> >>as you note.
> >
> >>I don't think it makes sense to use a tuning that specifically states
> >>that it can't run thumb code

yes. We should not have such case in armv7+ 

> 
> The defaulttune is supposed to supply what the processor and ABI are capable of.
> 
> So in the case of armv7a, it's saying no thumb support at all, this included
> thumb interwork.

if thats what we do then we are wrong. Since thumb interwork is
mandatory when we claim EABI compatibility and I think we have stopped
supporting Old ABI hence EABI is default which means interworking is
inherent.

> 
> armv7at says that the processor supports thumb, and interwork -should- be
> enabled.  (It can of course be manually disabled, but that's another issue
> to be dealt with...)

FWIW adding 't' in there should just be done when the resulting binary
is compiled using thumb ISA, using 't' to qualify interworking
capablility is not required.

> 
> armv7at doesn't say it actually includes thumb combines binaries.  (I argued
> originally it should, but was overruled for a variety of reasons... not the
> least of which is the interwork enabled, and multilib issues with 'same abi'
> configurations.)
> 
> So I agree the default should be armv7at or armv7at-neon, unless there is a
> compelling reason to leave it as a default with interwork disabled.

I dont believe thats the case we simply should not be able to disable
interworking.

> 
> As for the hard float question.  I'm torn on this.. for compatibility a lot
> of the industry is still soft-float based, and frankly I've not exactly
> encouraged it with my customers.. (I'm not seeing general performance
> improvements, only improvements in select artificial benchmarks, or specific
> pieces of code.)
> 
> But if changing the default to hard float were generally agreed upon (for
> architectures where VFP are available) then I wouldn't object.
> 

I would leave that choice to distributions for now