From: Martin Jansa <martin.jansa@gmail.com>
To: Peter Seebach <peter.seebach@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.
Date: Fri, 22 Aug 2014 23:46:26 +0200 [thread overview]
Message-ID: <20140822214626.GF20524@jama> (raw)
In-Reply-To: <20140822154954.04d4fc02@e6410-2>
[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]
On Fri, Aug 22, 2014 at 03:49:54PM -0500, Peter Seebach wrote:
> 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.
For me it's sane default for shared binary feed and DISTRO config is the
right place to decide common denominator for your MACHINEs (if all
MACHINEs you support are cortexa9 then yes, it would be better
DEFAULTTUNE, if you enable "thumb" in default ARM_INSTRUCTION_SET, then
yes it makes sense to enable it in DEFAULTTUNE as well, but 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.
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
and for webOS-ports we used it for a while and then reverted back to
default, because the difference between cortexa8-neon, cortexa9-neon and
armv8a-neon wasn't worth building and maintaining separate binary feed
(see links in .inc file)
https://github.com/webOS-ports/meta-webos-ports/blob/master/conf/distro/include/defaulttunes.inc
> 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.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
next prev parent reply other threads:[~2014-08-22 21:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 19:54 [PATCH 0/1] Change default for cortexa* to armv7at-neon Peter Seebach
2014-08-21 19:54 ` [PATCH 1/1] tune-cortexa*.inc: use armv7at by default Peter Seebach
2014-08-25 5:09 ` Khem Raj
2014-08-22 16:44 ` [PATCH 0/1] Change default for cortexa* to armv7at-neon Philip Balister
2014-08-22 18:33 ` Peter Seebach
2014-08-22 19:39 ` Martin Jansa
2014-08-22 20:49 ` Peter Seebach
2014-08-22 21:46 ` Martin Jansa [this message]
2014-08-22 22:06 ` Peter Seebach
2014-08-22 22:26 ` Martin Jansa
2014-08-25 19:12 ` Mark Hatle
2014-08-25 19:35 ` Khem Raj
2014-08-25 19:40 ` Mark Hatle
2014-08-25 20:40 ` Martin Jansa
2014-08-28 12:51 ` Philip Balister
2014-08-28 13:50 ` Koen Kooi
2014-08-28 13:57 ` Mark Hatle
2014-08-28 14:08 ` Koen Kooi
2014-08-28 14:21 ` Mark Hatle
2014-08-28 14:24 ` Mark Hatle
2014-08-29 6:12 ` Mike Looijmans
2014-08-29 12:16 ` Koen Kooi
2014-08-29 12:57 ` Mark Hatle
2014-08-24 23:51 ` Khem Raj
2014-08-24 7:56 ` Mike Looijmans
2014-08-24 14:44 ` Philip Balister
2014-08-24 18:15 ` Koen Kooi
2014-08-23 17:32 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140822214626.GF20524@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=peter.seebach@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox