On 19/04/12 17:36, Andrew Stubbs wrote:
On 18/04/12 21:47, Richard Sandiford wrote:
I still prefer the idea of disabling in the first pass. It'll need to
be tested on something like non-NEON ARM to see whether it makes things
worse or better there. (I think size testing would be fine.)
I'll have a go, and see what happens.
So far I've found that many examples give smaller code with this change,
and a few examples that give larger code. However, on average it appears
to give better code, size wise. This is on ARM when NEON is not enabled;
when NEON is enabled the results are far better, as expected.
I did have a small example that showed much worse register allocation,
but I can't reproduce that with the latest trunk.
Most of the size reductions can be explained by use of 64-bit loads and
stores, rather that pairs of 32-bit accesses.
In thumb mode, one cause of size increases appears to be that there are
no more instructions, but that it has used 32-bit opcodes rather than
16-bit ones; this is unfortunate.
Otherwise, it's very difficult to identify where the tiny size increases
come from.
As an example, I compiled (a slightly old copy of) gcc/expmed.c which
contains a lot of 64-bit operations, and compared the output sizes at
-O2. Of 43 functions, 37 show no change whatsoever, 5 showed a reduction
(21 bytes on average), and 1 function showed a 20 byte increase.
The end result is I'm going to try produce a proper patch to post.
Andrew
