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

[Evan Cheng]

On Jun 18, 2007, at 10:29 PM, Chris Lattner wrote:

>
> Hi Dan,
>
> I'm sorry to be such a pain, but this seems like a step backward.
> We've gone from having an explicit flag in the .td files to having
> another magic table in the .cpp file (somewhat amusing because
> 'duplicable' just made the opposite transition).
>
> 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);
>    }
>
> This achieves two things:
>
> 1. Just looking at the .td file, you can tell which instructions are
> candidates for remat.
> 2. The isRematerializable predicate is faster for instructions that
> are not remat-able.
> 3. The isReallyRematerializable only needs to be implemented by
> targets with instructions that are remat-able only in some cases
> (like the x86 instructions).

I okay'd Dan patch after considering the trade-offs. To me this gets  
rid of the duplicate instructions so it's worth it. Not to mention I  
had already considered the "trivial rematerialization" scheme to be  
temporary.

If we are really concerned about the speed, then I agree the hybrid  
approach is the best. Sorry about the confusion.

Evan

>
> To me, #1 is the killer feature.  In general, I'd like to move away
> from having tables (either explicit, like the one in
> X86RegisterInfo::foldMemoryOperand, or just big switch stmts) to
> having properties on .td file entries.  That makes it much more clear
> what is going on when inspecting the .td files.
>
> I'm sorry I didn't look at your patch when you asked for comments,
> but does this proposal sound sane?
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits