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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
