[LLVMdev] Re: InstructionSelectBasicBlock question
Vladimir Prus
ghost at cs.msu.su
Wed Mar 1 23:03:05 PST 2006
Chris Lattner wrote:
> On Wed, 1 Mar 2006, Vladimir Prus wrote:
>> I have two questions about the above method of the SelectionDAGISel
>> class.
>>
>> 1. The overrides in PPCDAGToDAGISel and in I64DAGToDAGISel are identical
>> (except for PPCISD::FIRST_NUMBER vs. IA64ISD::FIRST_NUMBER).
>> Maybe, this means that it would be better if SelectionDAGISel had default
>> implementation? That would remove this code duplication.
>
> Yup, that would be great.
>
>> 2. What are possible reasons for *not* using the default implementation?
>> X86 has completely different code, why?
>
> There are three different cases here:
>
> 1. In Sparc, we see simple and logical code to select a block.
> 2. In X86, it needs to do extra work to deal with the FP stack stuff
> after doing #1. This work is target-specific and shouldn't be needed
> by any other target.
> 3. In the case of PPC/Itanium, the code is *functionally* identical to #1,
> but includes some hacks that are designed to reduce the stack space
> usage of the instruction selector (darwin/ppc defaults to a really
> tiny
> stack, so these hacks are worthwhile. The IA64 presumably copied the
> implementation from the PPC backend).
Let me make sure I understand: the hacks are to reduce stack space of the
*instruction selector*? So, if I use PPC codegen on darwin/ppc, things will
work, but if I use X86 codegen on the same darwin/ppc machine, X86 won't
use those stack-space reducing hacks and stack with blow up?
> To me, I think it would make sense to move the implementation in the PPC
> backend up to the SelectionDAGISel class. The stack space reducing hacks
> can benefit all targets, and the algorithm is the same for all (like you
> said, except for the enum). The X86 backend can override it, explicitly
> call the superclass, then do the magic it wants.
To clarify, the base method should have implementation and should not be
pure, right?
> Would you be interested in working on this?
Yes, I hope to do this in near future.
Thanks,
Volodya
More information about the llvm-dev
mailing list