[OE-core] ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/9/12 4:30 PM, Phil Blundell wrote:
> On Mon, 2012-04-09 at 16:21 -0500, Mark Hatle wrote:
>> I do, and thus the hell that is ARM.  I could not currently generate a single
>> package feed that work would on a variety of devices (like a traditional
>> workstaton/server Linux OS would.)
>
> Well, actually, you could in fact do exactly that.  What you couldn't
> necessarily do with the tunings as they exist right now is generate a
> package feed which is optimised for (as opposed to "works on") all those
> devices.  But it isn't clear to me that you could do that with a
> "traditional workstaton/server" kind of distribution either.  In the x86
> world, for example, the majority of the big distros do not bother to
> ship individually-tuned binaries for different processor types,
> certainly not for the entire distribution.

Depends on the distribution and reasons for these feeds.  What is typical is 
that a base distribution will be generated for a common compatible (reasonable) 
architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl, 
etc) for the target arch, i.e. armv7a.  Then you have a couple of packages 
hand-tuned for size, speed, or other that define or not thumb and add even a 
higher level of optimization.  It's possible, folks do it today.. but it's not 
always obvious.  (I have existing customers today that run a mix like I 
described through their own package feed like system.  They really don't care at 
all that the core system is tuned for a given processor -- they only care that 
their specific applications and certain areas are specifically tuned to their 
use-cases.)  Note, this is not what I would consider a typical use-case!

>> Add in to that one of the tunings -- not indicated by the package arch
>> of thumb enabled or not
>
> There are multiple reasons why this isn't indicated by the PACKAGE_ARCH.
> Firstly, it's irrelevant: on v5T or newer, the question of whether a
> given package is using Thumb-state or not has no ABI impact and there is
> no reason for anyone to care at a compatibility level.  Second, it may
> be unpredictable: the compiler is at liberty (although current versions
> of gcc don't exploit this latitude) to switch arbitrarily between
> ARM-state and Thumb-state as it sees fit to get the best performance.
> And thirdly, it's just another piece of distro policy in the same way as
> compiling for -O2 vs -Os (which we also don't encode into PACKAGE_ARCH)
> is.

I agree, on ARM the tunings and optimizations between regular and thumb do not 
impact the ABI what-so-ever.  And so far compilers have to be explicitly set to 
do thumb or tranditional ARM mode.. so in the end developers are looking into 
the performance and size impacts of each of these configuration and making 
changes as they see fit to best meet their needs.  These are unique cases 
though, the majority of the software built for the core OS uses a single policy 
-- it's when something needs to be further optimized that this comes into play.

At this point, I'd "like" to better differentiate the ARM package arches..  I 
don't care so much about the thumb enabled or not.. but the other tune settings 
are things I do care about.  I started to change that for the last update and 
decided it was a rat-hole I was not willing to go down at this point.  At some 
point in the future, I will look at, and document the differences in the tunings 
according to GCC configurations -- to get a good idea of what is and isn't 
producing the same binaries based on various arch and tune settings.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core