[LLVMdev] Back end loop invariant opt

[Chris Lattner]

On Sat, 24 Mar 2007, Christopher Lamb wrote:
> It seems to me that there is potential for doing some target independent loop 
> invariant optimizations in the back end, but prior to instruction selection.

I assume you mean after instruction selection?

> For instance, I noticed that the loop invariant constant generated for a loop 
> bounds check is still stuck inside the loop. Likewise constant address 
> generated for globals accessed within a loop are generated on each iteration, 
> even though they are invariant.

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).

> I'm most familiar with LLVM's target interface and code gen and I'm not fully 
> up to speed on the optimization framework. Is there an existing optimization 
> pass that handles these cases that I've failed to properly enable or hook 
> into? Is there something that inherently prevents these from being target 
> independent optimizations, requiring a target specific opt pass? Is this 
> simply an optimization pass that hasn't been implemented yet, but is a good 
> idea?

The later.  On targets with few registers, LICM can be very bad.  Our plan 
is to implement rematerialization in the register allocator to counteract 
this.  In any case, I think that LICM should definitely be done, and 
targets can choose to use it or not based on their register file, before 
remat is done.

-Chris

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