[llvm-commits] CVS: llvm/lib/Target/X86/X86InstrFPStack.td X86InstrInfo.cpp X86InstrInfo.h X86InstrInfo.td X86InstrMMX.td X86InstrSSE.td

[Chris Lattner]

>> How about this proposal (Obviously feel free to pick better names for
>> these things):
>>
>> 1. Reintroduce the 'isremat-able' flag, set it to true for all the
>> instructions that are *potentially* rematerializable.
>> 2. Add a virtual target hook that can override the flag:
>> "TII::isReallyRematerializable(Machineinstr*)".
>> 3. Introduce a new non-virtual method:
>>    bool TII::isRematerializable(Machineinstr *MI) {
>>      return MI->flags->isrematable && isReallyRematerializable(MI);
>>    }
>
> I tried this, and got circular dependencies between libLLVMAnalysis.a,
> libLLVMTarget.a, and libLLVMCodeGen.a. I think it's because the actual
> code for 3. uses MachineInstr::getOpcode.

It shouldn't need to, it can be an inline function that calls:
    MI->getInstrDescriptor()->isrematable()

MachineInstrs have a direct pointer to their TargetInstrDescriptor  
record.  They actually don't hold their opcode :)

>> I'm sorry I didn't look at your patch when you asked for comments,
>> but does this proposal sound sane?
>
> *shrug*. Adding isReMaterializable flags to all the load  
> instructions in
> the X86 files isn't unambiguously prettier though. But I've already
> strayed from my tangent here :-}.

True, in the future we can add some smarts to tblgen... we already  
know what the loads are (from the patterns), so tblgen could do this  
automatically for every target.

Unfortunately, the tblgen code that interprets the patterns is built  
into the DAGISelEmitter.cpp file.  Someday we should refactor the  
code for interpreting the patterns out from the code that emits the  
isel.  That way, other tblgen backends could use the patterns to  
autogenerate things (e.g. the "fold load into instruction" code).

-Chris