On Mon, Oct 1, 2012 at 2:06 PM, Steven Bosscher <stevenb....@gmail.com> wrote: > 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 ;-)
;) Certainly an interesting idea. I wonder how much pseudos we allocate later during optimizations - thus, would sth like the SSA name freelist (and a way to formally release a pseudo, similar to release_ssa_name) improve the situation? I guess most of the wasted pseudos are created because we are not very good at generating initial RTL - are there maybe a few patterns we can do better on that would catch a big fraction of the waste? Thanks, Richard. > 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
