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

[Peter Seebach <peter.seebach@windriver.com>]

On Fri, 22 Aug 2014 21:39:10 +0200
Martin Jansa <martin.jansa@gmail.com> wrote:

> Even enabling thumb seems wrong, because ARM_INSTRUCTION_SET is arm by
> default, so this change is only renaming the feed, but still building
> the same binaries (unless distro sets ARM_INSTRUCTION_SET).

I think that's okay, because the point is to correctly indicate that
the CPU can run thumb binaries if someone had a reason to make them.

I mean, strictly speaking, I don't even *know of* an actual chip for which
armv7a-neon is a correct descriptor. Because "armv7a-neon" is a chip which
*cannot* run thumb binaries. Does anyone actually make a neon armv7a which
can't run thumb binaries?

And yeah, the RFC and ensuing discussion gets to some sort of underlying
questions about what the purpose of DEFAULTTUNE is. I am inclined to think
that the DEFAULTTUNE for a given tune-foo should be either the baseline of
that chipset or a somewhat optimized tune for it.

I note that tune-core2 and tune-corei7 both set tunes (core2-32, corei7-64)
which include target-specific optimizations; this would be comparable to
using cortexa9t-neon as the default tune for tune-cortexa9.inc.

I don't think the current state of tunings reflects a completely consistent
view of what DEFAULTTUNE means in a tuning file.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.