[llvm-commits] [llvm] r44960 - in /llvm/trunk: include/llvm/Target/ lib/CodeGen/ lib/Target/ lib/Target/ARM/ lib/Target/Alpha/ lib/Target/IA64/ lib/Target/Mips/ lib/Target/PowerPC/ lib/Target/Sparc/ lib/Target/X86/ test/CodeGen/X86/

[Evan Cheng]

On Dec 12, 2007, at 5:51 PM, Chris Lattner wrote:

>>>> At one point were discussed eliminating
>>>> TII::isTriviallyReMaterializable.  The argument is that target
>>>> implementations shouldn't have to know about algorithms, they  
>>>> should
>>>> just describe properties of the target, and the algorithm should
>>>> figure out if it can make the xform from that info.
>>>
>>> What do you mean? The targets don't know about the remat algorithm.
>>> It's just the spiller making use of a some property of the
>>> instructions.
>>
>> Ok, you are talking about isTriviallyReMaterializable, not
>> M_IMPLICIT_DEF_FLAG. Right now it is defined as this:
>
> Right.
>
>>    bool isTriviallyReMaterializable(MachineInstr *MI) const {
>>      return (MI->getInstrDescriptor()->Flags & M_REMATERIALIZIBLE) &&
>>             isReallyTriviallyReMaterializable(MI);
>>    }
>>
>> X86::isReallyTriviallyReMaterializable() is:
>> ...
>>    case X86::MMX_MOVD64rm:
>>    case X86::MMX_MOVQ64rm:
>>      // Loads from constant pools are trivially rematerializable.
>>      return MI->getOperand(1).isRegister() && MI->getOperand
>> (2).isImmediate() &&
>>             MI->getOperand(3).isRegister() && MI->getOperand
>> (4).isConstantPoolIndex() &&
>>             MI->getOperand(1).getReg() == 0 &&
>>             MI->getOperand(2).getImmedValue() == 1 &&
>>             MI->getOperand(3).getReg() == 0;
>>    }
>>
>> The targets is only describing properties of the instruction because
>> we are not able to describe addressing mode in a generic way. Seems
>> like we are not too far off from your "pipe dream". :-)
>
> aha!  How about we have some new property "can be moved with
> impunity" which laods from the constant pool would return true for?
> This property could then be used by licm and is better than calling
> it "rematerializable", which depends on the implementation of remat.

The problem is the property requires understanding of the MI  
addressing mode. There is no way to specify a static property to  
describe that. Unless we want to use different opcodes for  
constantpool load, for example.

>
> I'd like to nuke M_REMATERIALIZIBLE and
> isReallyTriviallyReMaterializable, replacing them with the properties
> that are actually needed.

I have no problem with nuking M_REMATERIALIZIBLE. We just have to  
replace it with something like M_HAS_SIDE_EFFECT. However, I am not  
sure how to eliminate isReallyTriviallyReMaterializable for reason  
described above.

Evan

>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits