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

[Philip Balister]

On 08/25/2014 03:12 PM, 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
> 
> 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.)

The artificial benchmarks are likely anything that includes functions
returning floating point numbers.

Philip

> 
> But if changing the default to hard float were generally agreed upon
> (for architectures where VFP are available) then I wouldn't object.
> 
> --Mark
> 
>> The problem is that "t" in DEFAULTUNE always adds "t2" to TUNE_PKGARCH
>> no matter if you've built the package with -marm or -mthumb. So as long
>> as ARM_INSTRUCTION_SET is "arm" by default, we should use the same
>> default for DEFAULTTUNE - I wouldn't mind changing ARM_INSTRUCTION_SET
>> at least more people will be hit by those ICEs I've reported earlier
>> (with patch forcing ARM_INSTRUCTION_SET to "arm" for gdb and icu
>> "gdb: force arm mode" http://patchwork.openembedded.org/patch/75703/
>> "icu: force arm mode" http://patchwork.openembedded.org/patch/75817/
>>
>> It would be interesting to try
>> http://patchwork.openembedded.org/patch/70985/
>> with latest master to see if it can work correctly now, then I wouldn't
>> be so opposed to "enabling" thumb in DEFAULTTUNE (even without
>> ARM_INSTRUCTION_SET change)
>>
>>>> Every distro can use something more "optimized" DEFAULTTUNEs for each
>>>> MACHINE they use, I do it for SHR:
>>>> https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc
>>>>
>>>
>>> Huh, that's an interesting point. I'll wave this at people and see
>>> what they
>>> think of it.
>>>
>>> -s
>>> -- 
>>> Listen, get this.  Nobody with a good compiler needs to be justified.
>>
>>
>>
>