David Edelsohn wrote: > ---------- Forwarded message ---------- > From: Albert Cohen <[email protected]> > Date: Sun, Jun 28, 2009 at 6:25 PM > Subject: Re: Register Pressure in Instruction Level Parallelism > To: Dave Korn <[email protected]> > Cc: [email protected], [email protected], Sid Touati > <[email protected]>, Frederic Brault <[email protected]> > > > Hi all, > > I'm convinced that saturation and sufficiency based approaches are the > future of register pressure management. > > [Please keep my colleague Sid Touati in CC of this thread, until he > registers to the list.] > > Unfortunately, the state of the art (more recent that the thesis > referenced in the original email, see Touati's web page) is limited to > basic block and software-pipelining scopes, and limited to scheduling. > > Compared to the tasks currently managed by reload, it certainly misses > a whole bunch of instruction selection and immediate operand/address > mode corner case problems (depending on the target). It also misses > global scheduling, but extended BB scheduling is not very hard to > approximate, as well as superblock scheduling. > > > I'm not at all a knowledgeable person to tell you what to do in the > case of GCC, but for sure saturation/sufficiency-based approches are > not sufficient to kill the dragon. > > However, I will strongly advise anybody (= Kenny Zadeck) looking at a > fresh SSA-based backend design to consider such an approach to avoid > messing up with pressure-aware-* where * is any backend pass that > bears a risk of blowing up register pressure. > > I am considering such a design and i did, late last week to go public with my project. I am now working to put up a project in the public spaces. I would very much like the help of anyone who is interested in working in this area to consider working on it in gcc.
kenny > If you interested in collaboration on the topic, we are about to start > extending those approaches to general control-flow, and implementing > it in a production compiler (not GCC, but a free one, and not LLVM > either). > > Albert > > > Dave Korn wrote: > >> Michael Kruse wrote: >> >> >>> So, now my questions: How much do you think could this could improve >>> compiled code speed? Would the current GCC/YARA benefit from such an >>> optimization pass at all? What are the chances that this could get into >>> the main GCC tree if it shows up to be an improvement? >>> >> One of the major problems in gcc is the intertangling of instruction >> selection with register allocation and spill generation. If these could be >> separated it would almost certainly generate better code and be welcomed with >> open arms! >> >> >>> I'd prefer to implement this for the gcc, but my advisor wants me to do >>> it for the university's own compiler. Therefore I could also need >>> arguments why to do it for the GCC. >>> >> Because destroying reload(*) would be an incalculable public service and >> your name will be remembered in history as the one who slew the dragon? ;-) >> >> cheers, >> DaveK >>
