[patch] experimenting with renumbering of pseudos after expand

Steven Bosscher stevenb.gcc@gmail.com
Mon Oct 1 12:07:00 GMT 2012


Hello,

For most code, expand creates a lot of pseudos that are cleaned up in
subsequent passes, if they even live long enough to make it there. On
average, for cc1 preprocessed source, the number of "holes" in
regno_reg_rtx is about half the size of that array, or in other words:
regno_reg_rtx is almost a sparse array.

I've been experimenting with the attached patch to renumber pseudos
just before initializing DF. For the already-notorious test case of
PR54146 on x86_64, the patch reduces max_reg_num from 348404 to 180502
for the largest function. This reduces the memory foot print of the
test case to less than 6GB, an almost 25% reduction, and it speeds up
the DF_LR and DF_LIVE problems a bit (~15% but that's not much on the
total compile time).

I had hopes that it would help for LRA compile times also, but
unfortunately the only significant change is this one:

without patch:
 LRA hard reg assignment : 130.85 (11%) usr   0.20 ( 1%) sys 131.17
(11%) wall       0 kB ( 0%) ggc

with patch:
 LRA hard reg assignment : 108.92 ( 9%) usr   0.07 ( 0%) sys 109.03 (
9%) wall       0 kB ( 0%) ggc

Anyway, putting the patch out there to show that I've done more than
just complaining ;-)

It also would suggest that the scalability challenge for LRA is not
the number of pseudos but something else (number of insns, I guess).

Ciao!
Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compact_regno_reg_rtx.diff
Type: application/octet-stream
Size: 2896 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20121001/64a7b6f6/attachment.obj>


More information about the Gcc-patches mailing list