This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]