[llvm-commits] [llvm] r82076 - in /llvm/trunk: include/llvm/LinkAllPasses.h include/llvm/Transforms/Scalar.h lib/CodeGen/LLVMTargetMachine.cpp lib/Transforms/Scalar/CodeGenLICM.cpp

Dan Gohman gohman at apple.com
Fri Sep 18 12:14:13 PDT 2009


On Sep 18, 2009, at 11:40 AM, Chris Lattner wrote:

>
> On Sep 16, 2009, at 1:25 PM, Dan Gohman wrote:
>
>> Author: djg
>> Date: Wed Sep 16 15:25:11 2009
>> New Revision: 82076
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=82076&view=rev
>> Log:
>> Add a new pass for doing late hoisting of floating-point and vector
>> constants out of loops. These aren't covered by the regular LICM
>> pass, because in LLVM IR constants don't require separate
>> instructions. They're not always covered by the MachineLICM pass
>> either, because it doesn't know how to unfold folded constant-pool
>> loads. This is somewhat experimental at this point, and off by
>> default.
>
> Hi Dan,
>
> I'm generally accepting of short term hacks to solve real problems,  
> but how hard would it be to just improve machine licm's handling of  
> loads from constant pools?

Yes, MachineLICM could call unfoldMemoryOperand on every instruction
in a loop with a constant-pool load folded into it and hoist what comes
out. It's debatable which approach is cleaner. However this wouldn't
affect your other concerns, because constants would be hoisted before
register allocation either way.

>  Hoisting on X86 is not necessarily a win because you can  
> substantially increase register pressure (always) and pulling the  
> constant pool load out of the loop will prevent it from being folded  
> into load+op instructions.

remat.

>
> This also looks like it hoists all zero vectors which are "very  
> cheap", not loads.  In general, I'm pretty dubious about this  
> approach.

They are cheap, but not free. And they are rematerializable.

Dan




More information about the llvm-commits mailing list