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