On Sat, Aug 24, 2013 at 8:17 AM, Richard Biener <richard.guent...@gmail.com> wrote: > Wei Mi <w...@google.com> wrote: >>Thanks Richard. Yes, without that restriction, the number of >>partitions in the partition map will be increased somewhat. But I >>think it may not increase a lot for 2 reasons. 1. usually coalesce >>list is not a very big list and only the vars in that list will be >>added to conflict graph. It already reduces conflict graph bitmaps a >>lot. 2. a ssa var may appear in multiple phi stmts. Suppose in >>phi-stmt1 it has different basename with other phi arg, while in >>phi-stmt2 it has the same basename with other phi arg. In such case, >>the ssa var will be added to conflict graph anyway because of >>phi-stmt2, but it will not be added to coalesce list for phi-stmt1 >>with the restriction. So the restriction block the coalesce >>opportunity in phi-stmt1 without reducing memory. >> >>I hacked the out-of-ssa phase and added different names var in the >>same phi into coalesce list. I tried spec2000 int and saw no >>significant memory increase for expand phase (I used your -fmem-report >>patch to dump the memory usage of each pass. It is useful. I am >>wondering why it didn't go into the trunk). > > You probably should dig in history as to for what bug this restriction was > added. Coalescing different variables will also degrade debug information. > > Note that artificial variables should nowadays be anonymous ssa names.
Just for some odd reason came back to this ... you can try the following patch and see if it helps. Richard.
p2
Description: Binary data
