[LLVMdev] Constant Propagation Problem

Chris Lattner sabre at nondot.org
Wed Jan 19 08:32:23 PST 2005


On Wed, 19 Jan 2005, Morten Ofstad wrote:

> Hello,
> I have some code which I was hoping the LLVM optimization passes would get 
> rid of for me, but no such luck -- all the code does is store four float 0.f 
> to memory, load four other floats from memory, load back the first four 
> floats, multiply them together (here we should have always get 0) and finally 
> store them back to memory. Any ideas why this isn't picked up by the constant 
> propagation?

There are two passes that can help you here.  -scalar-repl (which you have 
below) will take a structure/array on the stack and split it up into 
elements, turning each element into an SSA register.  This applies to 
aggregates that are only used by getelementptr instructions with constant 
indices, whose elements are loaded or stored to (basically you can't pass 
the address of the structure or its components around to functions, store 
the address anywhere, etc).

You don't show the definition of "%Color", but I assume it's on the stack. 
Another thing to note is that allocas in entry blocks are MUCH more 
efficient than allocas in the body of the function.  Things like mem2reg 
and scalarrepl only work on these (for example) and they end up being 
statically allocated on the stack if they can't be optimized away.

The other option, which is generally more powerful than (but not always a 
replacement for) -scalar-repl is the -gcse pass when combined with the 
-load-vn pass.  This will do the "copy propagation through memory" that 
you are looking for, turning code like this:

   store int %A, int* %P
   %B = load int* %P
   %C = %B + 1

into this:

   store int %A, int* %P
   %C = %A + 1

Note that this will leave dead stores laying around, so the -dse pass may 
be useful after -load-vn -gcse.

The problem with -load-vn and -dse is that they rely on alias analysis to 
do their job, and alias analysis sometimes gets confused.  If you want to 
see what queries a client is making, you can use the -count-aa pass on the 
command line to do this.  Something like this should work:

  $ opt -count-aa -load-vn -gcse foo.bc -stats -disable-output

That will run the optimization and print out a report of how many 
may/must/no alias responses were returned.

Let me know if this helps, my guess is that -load-vn -gcse will do the 
trick for you.

-Chris



> PS. I'm running the following passes (which is certainly overkill, I based it 
> partly on the llvm-ld Optimize.cpp and added all the optimizations I could 
> find which run on Functions, I don't need the IP optimizers):
>
> LowerPackedPass
> CFGSimplificationPass
> PromoteMemoryToRegister
> InstructionCombiningPass
> CFGSimplificationPass
> RaisePointerReferencesPass
> TailDuplicationPass
> CFGSimplificationPass
> ScalarReplAggregatesPass
> InstructionCombiningPass
> ReassociatePass
> InstructionCombiningPass
> TailCallEliminationPass
> CFGSimplificationPass
> LICMPass
> InstructionCombiningPass
> IndVarSimplifyPass
> LoopUnrollPass
> InstructionCombiningPass
> GCSEPass
> SCCPPass
> InstructionCombiningPass
> DeadStoreEliminationPass
> AggressiveDCEPass
> CFGSimplificationPass
>
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/




More information about the llvm-dev mailing list