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

[Martin Jansa]

On Mon, Aug 25, 2014 at 12:35:23PM -0700, Khem Raj wrote:
> 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.

That's what
http://patchwork.openembedded.org/patch/70985/
was trying to fix.

Now we add t (or t2) for every DEFAULTTUNE which adds thumb to
TUNE_FEATURES (for packages with both thumb and arm ISA).

> > 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
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140825/c53278e8/attachment-0002.sig>