[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 17:51:04 PST 2007
>>> 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.
I'd like to nuke M_REMATERIALIZIBLE and
isReallyTriviallyReMaterializable, replacing them with the properties
that are actually needed.
-Chris
More information about the llvm-commits
mailing list