On Sat, 2006-06-24 at 12:36 -0400, Vladimir N. Makarov wrote: > Steven Bosscher wrote:
> As for Andrew's proposal, my opinion is that all this > transformations are done too early and we need them to do again on > rtl sometime. > > o coalescing. CSE can create more moves but more important thing is RABLET will do nothing different than is done today.. out of ssa coalesces ssa_names out the wazoo. In the interest of register pressure reduction, it may actually coalesce less to split up live ranges, and leave loads/stores from/to the stack. > > o register pressure relief through live range splitting and/or > rematerialization. We have no accurate information here, because > after that there are passes which change the pressure like insn Sure, Im not suggesting that RABLET will reduce the register pressure to something that isn't going to spill. Far from it. I am saying that RABLET can reduce something completely unmanageable to something more manageable. instead of handing the RTL passes a basic block that contains a peak register pressure of 120 when there are 16 hardware registers, perhaps it will be a basic block that has been reduced down to a peak of 25 or something. The calculations at the tree level are only going to be rough, enough to use as a guideline like that. If RA doesnt have to spill its guts, it has a chance to do a better job I think. > scheduling and CSE. Although insn scheduling has heuristic not to > increase register pressure, it has very small priority (third or > fourth). Therefore insn scheduling can increase the pressure a lot sure, but it wont increase it from 25 back up to 140, so there should still be benefit. > Actually what Andrew proposes (and more) I did two years ago on RTL > level close to the register allocator (see gcc summit article > "fighting register pressure in gcc"). The result was not satisfactory > for me and I moved on rewriting the register allocator. Probably, I > should have committed more what I've done into the mainline. > I think its hard to do what I am going to do at the RTL level. I have all the information from tree-ssa available to make quite a few interesting decisions. and with a rewritten expand, decisions about whether things are regisrer or memory based can be made more fine grain. It just seems like the last good place to do some of this work. ANd perhaps we can get better instructions selected by seeing more that expand currently sees. > Probably what Andrew proposes can be done faster on tree-SSA > although doing it on RTL we would have more accurate information. In > any case it will improve code in some cases and can be used as a > temporary solution (until new register allocator projects will be done > or forever if they failed). Andrew's proposal has a sense too with > the code reuse point of view if he wants to move on with RABLE > project. we'll see if that ever happens :-) Im hoping RABLET makes it less urgent. If not, then its time to consider something different, perhaps some of the key individual compents such as forced instructoin selection can be done, or maybe YARA will be a success and you'll take care of it! Andrew
