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

[Koen Kooi]

Op 28 aug. 2014, om 15:57 heeft Mark Hatle <mark.hatle at windriver.com> het volgende geschreven:

> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>> 
>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle at windriver.com> het volgende geschreven:
>> 
>>> 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
>>> 
>>> 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.
>>> 
>>> 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...)
>>> 
>>> 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.
>>> 
>>> 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.)
>> 
>> Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.
>> 
> 
> Exactly.  Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.
> 
> If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful.  But this is fairly artificial in most of the embedded workloads I'm familiar with.
> 
> So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being).  I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon.

Thumb1 support has never been stable, so I don't see what it will buy us. It just seems a way to piss of DISTROs without any benefits.