[oe] [RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[Paul Sokolovsky]

Hello Koen,

Thursday, December 21, 2006, 8:21:50 PM, you wrote:

[]

>>> Today I seperated the thumb bits from
>>> conf/machine/include/ipx4xx.conf into
>>> conf/machine/include/. I'd like to enable for all >=v5t machines, but I'm unsure about
>>> using positive or negative logic.
>> 
>>   What about armv4t?

> The codesourcery people are telling horror stories to everyone about armv4t, but I don't
> believe them anymore after
> http://www.openembedded.org/repo/org.openembedded.dev/packages/gcc/gcc-4.1.1/unbreak-armv4t.patch
> 'fixed' EABI on armv4t. I get the distinct feeling csl is trying to strongarm people into
> using armv5 and armv6.

>>  plus, thumb has known drawback of reduced performance.

> I know the 'bx' insn causes a pipeline flush on xscales, any other drawbacks? And more
> importantly, any numbers?

  Well common Thumb intros usually have something like "Using Thumb
can usually reduce code size 1.5 times, while reducing performance by
20% because of longer instruction sequences for some operations.".
Or at least so I think. Because it turned out surprisingly hard to
find a link for that ;-). I finally found a pretty good academic
report: http://www.cs.arizona.edu/~gupta/research/Publications/Comp/L14-krishnaswamy.pdf

"""
While the use of Thumb instructions generally gives smaller code
size and lower instruction cache energy, there are certain problems
with using the Thumb mode. In many cases the reductions in code
size are obtained at the expense of a significant increase in the number
of instructions executed by the program. In our experiments
this increase ranged from 9% to 41%.
"""

  As each thumb instr maps to one ARM, those percentages are exactly
performance loss. So, we don't really want Thumb for gstreamer,
mpalyer, and glibc (sic!, way to reduce libc's footprint is obviously
to use uclibc ;-)).

  Two other common benefits of Thumb quoted are reduced memory
bandwidth requirements (like, can use 16bit memory), and cache
efficiency (including power) - but before we start optimize cache
usage, there'er few more significant things to do, like supporting
CPU idle modes, using dynticks, etc.


  So, two criteria above doesn't apply to us much, and indeed, it
appears that Thumb vs ARM instr. set is code size vs code
performance dichotomy in our case.


>> In ideal case, thumb usage would be set per-package

> Yes, that's where ARM_INSTRUCTION_SET comes in :), although enabling it is messier as
> disabling it.
> I wasn't impressed by the numbers[1], but samba lost 0.5MB, so that's a candidate

  Ok, good plan.

> regards,

> Koen

> [1] Angstrom already uses -Os, so the binaries are already pretty small

[]


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com