This is the mail archive of the
mailing list for the GCC project.
Re: Why does lower-subreg mark copied pseudos as "decomposable"?
- From: Andrew Stubbs <ams at codesourcery dot com>
- Cc: <gcc at gcc dot gnu dot org>, <rdsandiford at googlemail dot com>
- Date: Fri, 4 May 2012 21:53:00 +0100
- Subject: Re: Why does lower-subreg mark copied pseudos as "decomposable"?
- References: <4F8D8E21.firstname.lastname@example.org> <email@example.com> <4F8DE0E6.firstname.lastname@example.org> <email@example.com> <4F8EA900.firstname.lastname@example.org> <email@example.com> <4F8F1785.firstname.lastname@example.org> <email@example.com> <4F903F25.firstname.lastname@example.org>
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
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.