[LLVMdev] Back end loop invariant opt

Chris Lattner sabre at nondot.org
Sun Mar 25 15:20:10 PDT 2007


On Sun, 25 Mar 2007, Christopher Lamb wrote:
>>  I assume you mean after instruction selection?
>
> I assumed that to be target independent the pass would need to be before 
> instruction selection, but I guess if the pass more like the basic block/ 
> branch analysis that would make sense.

Right.  We already have LICM that runs before isel.  THe problem is that 
isel exposes new opportunities for LICM.

>>  Yes, this is a known issue.  The plan is to implement a machine-code level
>>  pass that hoists machine instrs out of loops after instruction selection
>>  has been performed.  This is important, because isel is the pass that
>>  exposes most of the issues that need hoisting (e.g. load immediate
>>  instructions, etc).
>
> Isn't it possible to tell that certain DAG nodes are loop invariant prior to 
> instruction selection, such as a constant or global address node?

Yes.  The problem is that selectiondags are currently only built per-basic 
block, so you can't do whole-function code motion xforms on them.  In the 
long term, this is certainly something I want to fix.  See Cliff Click's 
thesis for some of the things you can do with whole-function dags.

>>  targets can choose to use it or not based on their register file, before
>>  remat is done.
>
> Is there more information (PR?) on the schedule for this work and who is 
> involved? I may not be experienced enough to make much of a contribution yet, 
> but I'd like to keep tabs on it.

We have very simple remat implemented, basically for instructions that 
have no input registers and define a single output register.  We don't 
have any immediately-short-term plans to implement either machine code 
LICM or the rest of remat.

In the medium term (6-18 months), I'd like to start a major redesign 
project for the register allocator.  The goal would be to build a 
framework to handle standard techniques like shrink wrapping, live rangle 
splitting, remat, ra resched, etc.

In the shorter term, there are still lots of other things that can be 
improved, on shorter time scales, for now we are focusing on those.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/



More information about the llvm-dev mailing list