On Sat, 2006-06-24 at 13:04 +0200, Steven Bosscher wrote: > On 6/24/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote: > >= > > In general, I didnt mention anything that tends not to increase register > > pressure, at least not in any significant manner as far as RABLET is > > concerned. > > So do you have hard data showing that CSE increases register pressure? > Given the thinks CSE does, it would probably be much more useful, > then, to make it possible to have liveness information in CSE so that > it can take register pressure into account in its cost considerations > ;-) No magic new expand is going to make CSE obsolete, and it simply > does too much to just throw it out. (FWIW I'm still working on > simplifying cse.c...)
no, no hard data, its just the kind of activity which can undo what RABLET proposes doing. Ie, an expression which I go to the effort to rematerializing in 3 places is likely to be commoned back to the original live range without stepping in and telling CSE not to do that. What I really had in mind was marking these register values/expression/whatever with a flag such that when CSE or GCSE or whoever asks, they get returned as not-to-be-looked-at. That way they don't undo the "opportunities" which RABLET has so kindly exposed to these optimizations :-) > > > Clearly there will be a lot of further investigation required once > > implementation reaches this point. Ultimately CSE and all RTL > > optimizations can be re-evaluated to see if things can be simplified. > > *laughs* > > Every time some RTL optimizer is re-re-re-re-re-evaluated, it turns > out we lose without it. Good luck to you, but I think you're seriously > underestimating the complexity of things here. I was not really looking to rewrite the passes so much as tell them not to work on certain registers. This could potentially be extended to ssa_names which the tree optimizers have processed and which get expanded into single RTL registers. A new expand would know that the translation into RTL was simple enough that nothing new has really been exposed to the RTL optimizers. That was my thought anyway. Then CSE et al work on whatever is left. Perhaps there are then some hunks that can be remoived as redundant, or maybe not. > > Its clearly not as good as a new register allocator would be, but the > > effort to benefit ratio ought to be a lot higher for RABLET than for a > > register allocator rewrite. > > There is a register allocator rewrite under way, from one of your > co-workers even. Is there any relation between Vlad's project and > yours, or are you going different ways with the same goal in mind? :-D Totally different scale of project with completely different goal. Had I set out and actually started writing RABLE, that would be going in different directions with the same goal. In theory, RABLET should make the job of any register allocator a bit easier. These days, I think any register allocator's goal ought to be to assign registers and be the final authority. No reload undoing any of the work. That is well beyond the scope of what Im doing. It is within the scope of what Vlad is doing. Andrew
