Dear there, I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. My initial thought is: (1) I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. but looks it is not the case. (2) Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16).. wondering which part I missed? best Kevin
On 02/05/2015 01:56 PM, kewuzhang wrote:> Dear there, > > I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. > My initial thought is:Why do you need to do this? If you don't report having a 16-bit register type, all 16-bit operations should be appropriately promoted to 32-bit automatically? -Matt> (1) > I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. > but looks it is not the case. > > (2) > Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16).. > > wondering which part I missed? > > best > > Kevin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, Feb 05, 2015 at 04:56:25PM -0500, kewuzhang wrote:> Dear there, > > I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.If you want to make 16-bit types legal you need to call: addRegisterClass(MVT::i16, SomeRegisterClass) in your Target's TargetLowering implementation.> My initial thought is: > (1) > I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. > but looks it is not the case. > > (2) > Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16).. >Promoting ISD::ADD is not supported. Take a look in SelectionDAGLegalize::PromoteNode() to see which opcodes can be promoted. You will either need to custome lower it or properly handle it in the PromoteNode() function. -Tom> wondering which part I missed? > > best > > Kevin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Feb 5, 2015, at 5:41 PM, Tom Stellard <tom at stellard.net> wrote:> On Thu, Feb 05, 2015 at 04:56:25PM -0500, kewuzhang wrote: >> Dear there, >> >> I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. > > If you want to make 16-bit types legal you need to call: > > addRegisterClass(MVT::i16, SomeRegisterClass) in your Target's TargetLowering > implementation. >yeah., it is working.>> My initial thought is: >> (1) >> I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. >> but looks it is not the case.——————how to understand the “promote” in CallingConv.td?>> >> (2) >> Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16).. >> > > Promoting ISD::ADD is not supported. Take a look in SelectionDAGLegalize::PromoteNode() > to see which opcodes can be promoted. You will either need to custome lower it or > properly handle it in the PromoteNode() function.thank you very much! Think I run into this problem as well, it made me think the Promote is not working. best> -Tom > >> wondering which part I missed? >> >> best >> >> Kevin >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Feb 5, 2015, at 5:37 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:> On 02/05/2015 01:56 PM, kewuzhang wrote: >> Dear there, >> >> I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. >> My initial thought is: > Why do you need to do this? If you don't report having a 16-bit register type, all 16-bit operations should be appropriately promoted to 32-bit automatically?Thank you! I will discuss with team about this! Best Kevin> > -Matt > >> (1) >> I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. >> but looks it is not the case. >> >> (2) >> Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16).. >> >> wondering which part I missed? >> >> best >> >> Kevin >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Adding back llvmdev. On Tue, Feb 17, 2015 at 09:34:31AM -0500, Tom Stellard wrote:> On Mon, Feb 16, 2015 at 02:32:36PM -0500, kewuzhang wrote: > > > > Hi Tom, > > > > Talking about promoting operations. > > > > for i16 type ADD, I promoted it in the tablegen by creating a pattern > > “ > > def: Pat< (i16 (add i16:$src1 i16:$src2)), ( IADDs i16:$src1 i16:$src2)> > > “ > > What you've done isn't considered 'promotion'. This pattern tells the > instruction selector to *select* i16 add to the IADDs instruction. > > > seems my backend did not complain. > > and my IADDs is defined as a i32 + i32. I also have the i16 defined, which is same as i32 register > > If the register class you use for IADDs is defined with both i32 and i16 > types (which appears to be the case based on your description), then > it is expected that the above pattern will work. > > > > my questions are: (1) does i16 is automatically promoted? or just lucky? > > (2) I think I should make the pattern to something like: > > “ > > def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))> > > “ > > This pattern is emulating 16-bit addition using a 32-bit add. > If you have native 16-bit instructions then you shouldn't use this > pattern. > > -Tom > > > because the return value is i16 too. > > Is it necessary? > > > > > > best > > > > kevin > > > > > > > > Promoting ISD::ADD is not supported. Take a look in SelectionDAGLegalize::PromoteNode() > > > to see which opcodes can be promoted. You will either need to custome lower it or > > > properly handle it in the PromoteNode() function. > > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Hi guys, Talking about the following issue: ">> “ >> def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))> >> “ > > This pattern is emulating 16-bit addition using a 32-bit add. > If you have native 16-bit instructions then you shouldn't use this > pattern. > > -Tom“ Since I don’t have the native 16 bit operation support, I am going to “emulate” the operations using the corresponding 32 bits ops. So I need the pattens like it is in above, or something like " def: Pat< (i16 (add i16:$src1 i16:$src2)), ( trunc ( IADDs (zext i16:$src1) (zext i16:$src2)))> “ of course, this pattern will not work, because the llvm node “trunc”, “zext” appears in the output patterns. However, my “trunc”, “zext” is defined as patterns, so I don’t have something native supported like “TRUNCsr”, “ZEXTsr”. How to solve those conflicts? Best Kevin
On Feb 19, 2015, at 11:58 AM, kewuzhang <kewu.zhang at amd.com> wrote:> > Hi guys, > Talking about the following issue: > " >>> “ >>> def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))> >>> “ >> >> This pattern is emulating 16-bit addition using a 32-bit add. >> If you have native 16-bit instructions then you shouldn't use this >> pattern. >> >> -Tom > > “ > Since I don’t have the native 16 bit operation support, I am going to “emulate” the operations using the corresponding 32 bits ops. > So I need the pattens like it is in above, or something like > " > def: Pat< (i16 (add i16:$src1 i16:$src2)), ( trunc ( IADDs (zext i16:$src1) (zext i16:$src2)))> > “ > of course, this pattern will not work, because the llvm node “trunc”, “zext” appears in the output patterns. > However, my “trunc”, “zext” is defined as patterns, so I don’t have something native supported like “TRUNCsr”, “ZEXTsr”. > > How to solve those conflicts?Just don’t want to copy the stuff which is implementing the “zext”, “trunc” into my new pattern.> > > Best > > Kevin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, Feb 19, 2015 at 11:58:44AM -0500, kewuzhang wrote:> > Hi guys, > Talking about the following issue: > " > >> “ > >> def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))> > >> “ > > > > This pattern is emulating 16-bit addition using a 32-bit add. > > If you have native 16-bit instructions then you shouldn't use this > > pattern. > > > > -Tom > > “ > Since I don’t have the native 16 bit operation support, I am going to “emulate” the operations using the corresponding 32 bits ops. > So I need the pattens like it is in above, or something like > " > def: Pat< (i16 (add i16:$src1 i16:$src2)), ( trunc ( IADDs (zext i16:$src1) (zext i16:$src2)))> > “ > of course, this pattern will not work, because the llvm node “trunc”, “zext” appears in the output patterns. > However, my “trunc”, “zext” is defined as patterns, so I don’t have something native supported like “TRUNCsr”, “ZEXTsr”. > > How to solve those conflicts? >If you don't support native i16 operations, then don't declare i16 as a legal type and llvm will automatically promote these nodes using 32-bit ops. Then you will only need patterns for 32-bit instructions. -Tom> > Best > > Kevin
Possibly Parallel Threads
- [LLVMdev] local variable in Pattern definition?
- [LLVMdev] Question on tablegen
- [LLVMdev] Simpler types in TableGen isel patterns
- [LLVMdev] X86 disassembler & assembler mismatch
- [LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits