Why does lower-subreg mark copied pseudos as "decomposable"?

[Andrew Stubbs]

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