On Wed, 2008-10-01 at 11:12 +0200, Duncan Sands wrote:> Hi, > > > I have another query related to type legalizer. > > Can a target ignore certain nodes during legalize? Probably a hook for > > target that can be called inside IgnoreNodeResults ()? > > while this could be done, I don't like the idea of doing an end-run > around the whole type legalization infrastructure. So you would have > to come up with a pretty convincing argument as to why this can't be > done another way! > > > We want to keep certain nodes illegal, especially the pointer nodes. > > Our target has 16-bit pointer and a few 16-bit insns to perform > > arithmetic. > > Rest of the stuff is 8-bit so we want to use legalizer to expand them. > > I think x86-32 is capable of doing a small number of 64 bit operations. > I wonder how they are handled/generated given that i64 is not a legal type? >They might be using DAGCombine to convert the operations back to 64-bit. Also, the pointer is still a legal type (i32) in X86-32. In our case the pointers themselves are illegal (i16). We have 16-bit registers that can only hold pointers during indirect addressing. All other operations and registers are 8-bit. So we still want to expand everything to 8-bit but still keep the pointer nodes as an i16 node, a pair that in turn holds the expanded parts. - Sanjiv> Ciao, > > Duncan.
On Oct 1, 2008, at 3:01 AM, sanjiv gupta wrote:> On Wed, 2008-10-01 at 11:12 +0200, Duncan Sands wrote: >> Hi, >> >>> I have another query related to type legalizer. >>> Can a target ignore certain nodes during legalize? Probably a hook >>> for >>> target that can be called inside IgnoreNodeResults ()? >> >> while this could be done, I don't like the idea of doing an end-run >> around the whole type legalization infrastructure. So you would have >> to come up with a pretty convincing argument as to why this can't be >> done another way! >> >>> We want to keep certain nodes illegal, especially the pointer nodes. >>> Our target has 16-bit pointer and a few 16-bit insns to perform >>> arithmetic. >>> Rest of the stuff is 8-bit so we want to use legalizer to expand >>> them. >> >> I think x86-32 is capable of doing a small number of 64 bit >> operations. >> I wonder how they are handled/generated given that i64 is not a >> legal type? >> > They might be using DAGCombine to convert the operations back to 64- > bit. > Also, the pointer is still a legal type (i32) in X86-32. > > In our case the pointers themselves are illegal (i16). We have 16-bit > registers that can only hold pointers during indirect addressing. All > other operations and registers are 8-bit. So we still want to expand > everything to 8-bit but still keep the pointer nodes as an i16 node, a > pair that in turn holds the expanded parts.So you have a i16 register class which makes the type legal. You can make loads and stores legal (can you?). But you will have to custom lower all other i16 operations. This will work, but it requires a lot of target specific code. Evan> > > - Sanjiv > > > > > >> Ciao, >> >> Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > So you have a i16 register class which makes the type legal. You can > make loads and stores legal (can you?). But you will have to custom > lower all other i16 operations. This will work, but it requires a lot > of target specific code.True. If we add the i16 reg class we will need to write a lot of target specific code. To avoid that our idea was not to tell the legalizer about the i16 regclass and let it expand everything but ignore the pointers. - Sanjiv> > > > > > > > > > > >> Ciao, > >> > >> Duncan. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, 2008-10-01 at 23:39 -0700, Evan Cheng wrote:> On Oct 1, 2008, at 3:01 AM, sanjiv gupta wrote: > > > On Wed, 2008-10-01 at 11:12 +0200, Duncan Sands wrote: > >> Hi, > >> > >>> I have another query related to type legalizer. > >>> Can a target ignore certain nodes during legalize? Probably a hook > >>> for > >>> target that can be called inside IgnoreNodeResults ()? > >> > >> while this could be done, I don't like the idea of doing an end-run > >> around the whole type legalization infrastructure. So you would have > >> to come up with a pretty convincing argument as to why this can't be > >> done another way! > >> > >>> We want to keep certain nodes illegal, especially the pointer nodes. > >>> Our target has 16-bit pointer and a few 16-bit insns to perform > >>> arithmetic. > >>> Rest of the stuff is 8-bit so we want to use legalizer to expand > >>> them. > >> > >> I think x86-32 is capable of doing a small number of 64 bit > >> operations. > >> I wonder how they are handled/generated given that i64 is not a > >> legal type? > >> > > They might be using DAGCombine to convert the operations back to 64- > > bit. > > Also, the pointer is still a legal type (i32) in X86-32. > > > > In our case the pointers themselves are illegal (i16). We have 16-bit > > registers that can only hold pointers during indirect addressing. All > > other operations and registers are 8-bit. So we still want to expand > > everything to 8-bit but still keep the pointer nodes as an i16 node, a > > pair that in turn holds the expanded parts. > > So you have a i16 register class which makes the type legal. You can > make loads and stores legal (can you?). But you will have to custom > lower all other i16 operations. This will work, but it requires a lot > of target specific code. > > Evan >These i16 regs are actually pairs of 8-bit regs, So the other way for us is to have only 8-bit regclass and to use custom nodes for load/store that hold both the hi and lo parts of the pointer. - Sanjiv> > > > > > - Sanjiv > > > > > > > > > > > >> Ciao, > >> > >> Duncan. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev