Hi, 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. If desired, SelectionDAGISel can have both implementation and be pure, so that derived class authors are forced to think how they want this method to behave, and still have the option to call the default implementation. 2. What are possible reasons for *not* using the default implementation? X86 has completely different code, why? Thanks, Volodya
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.And the Sparc backend has a much simpler implementation, so it seems that the huge loop in PPC and I64 implementation is just no longer needed? - Volodya
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). 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. Would you be interested in working on this? -Chris -- http://nondot.org/sabre/ http://llvm.org/
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
Maybe Matching Threads
- [LLVMdev] InstructionSelectBasicBlock question
- [LLVMdev] InstructionSelectBasicBlock question
- [LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
- [LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
- [LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC