[llvm-commits] [llvm] r85364 - in /llvm/trunk: lib/CodeGen/MachineLICM.cpp test/CodeGen/X86/pic-load-remat.ll test/CodeGen/X86/sink-hoist.ll

Dan Gohman gohman at apple.com
Thu Oct 29 13:44:21 PDT 2009


On Oct 28, 2009, at 9:36 PM, Chris Lattner wrote:

> On Oct 27, 2009, at 8:22 PM, Dan Gohman wrote:
> 
>> Author: djg
>> Date: Tue Oct 27 22:21:57 2009
>> New Revision: 85364
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=85364&view=rev
>> Log:
>> Teach MachineLICM to unfold loads from constant memory from
>> otherwise unhoistable instructions in order to allow the loads
>> to be hoisted.
> 
> Nice.
> 
>> +    if (const PseudoSourceValue *PSV =
>> +          dyn_cast<PseudoSourceValue>(MMO->getValue())) {
>> +      if (!PSV->isConstant(MF.getFrameInfo())) return;
>> +    } else {
>> +      if (!AA->pointsToConstantMemory(MMO->getValue())) return;
>> +    }
> 
> eww, yuck :).  MachineLICM shouldn't have this logic.. a mythical CodeGenAA pass should.  Not super time critical of course.

Yes, that is the idea.

>> +    SmallVector<MachineInstr *, 1> NewMIs;
> 
> There isn't much harm in making this size 2 (since that's what the code expects) or even 4 if you want to be crazy. :)

This one was a mistake; it's fixed now.

> 
>> +    bool Success =
>> +      TII->unfoldMemoryOperand(MF, MI, Reg,
>> +                               /*UnfoldLoad=*/true, /*UnfoldStore=*/false,
>> +                               NewMIs);
>> +    (void)Success;
>> +    assert(Success &&
>> +           "unfoldMemoryOperand failed when getOpcodeAfterMemoryUnfold "
>> +           "succeeded!");
>> +    assert(NewMIs.size() == 2 &&
>> +           "Unfolded a load into multiple instructions!");
>> +    MachineBasicBlock *MBB = MI->getParent();
>> +    MBB->insert(MI, NewMIs[0]);
>> +    MBB->insert(MI, NewMIs[1]);
>> +    MI->eraseFromParent();
> 
> Please factor the 'memory operand hoisting' logic *out* of 'Hoist' into a helper function.

Fixed.

>> +    // If unfolding produced a load that wasn't loop-invariant or profitable to
>> +    // hoist, re-fold it to undo the damage.
>> +    if (!IsLoopInvariantInst(*NewMIs[0]) || !IsProfitableToHoist(*NewMIs[0])) {
>> +      SmallVector<unsigned, 1> Ops;
> 
> Again, why size 1?

Because that's all it would normally need? Anyway,
this code was removed in a subsequent simplification.

>> +++ llvm/trunk/test/CodeGen/X86/pic-load-remat.ll Tue Oct 27 22:21:57 2009
>> @@ -1,4 +1,10 @@
>> ; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+sse2 -relocation-model=pic | grep psllw | grep pb
>> +; XFAIL: *
>> +
>> +; This is XFAIL'd because MachineLICM is now hoisting all of the loads, and the pic
>> +; base appears killed in the entry block when remat is making its decisions. Remat's
>> +; simple heuristic decides against rematting because it doesn't want to extend the
>> +; live-range of the pic base; this isn't necessarily optimal.
> 
> Please don't leave this XFAIL unless you plan to 'fix' it.  Either change the expected output or remove the test (moving the issue to a readme).

I'd like to look into the hidden option to enable the feature which
fixes this.

Dan





More information about the llvm-commits mailing list