[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/

Chris Lattner clattner at apple.com
Wed Dec 12 20:09:53 PST 2007


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

Sure, I'm not arguing for a static flag on the TII instead of a  
virtual method.  I'm really saying that you should rename  
TII::isReallyTriviallyReMaterializable (which is virtual) to  
TII::isLoadConstant (which remains virtual) if that is what it really  
is.

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

Ok.  Really I'm talking about naming it better and changing the  
targets from providing "what remat wants" to providing abstract  
properties of their ISA.  If this ends up being a method rename, so be  
it :)

-Chris



More information about the llvm-commits mailing list