Dan
2013-Jul-30 19:14 UTC
[LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
I'll try to run through the scenario: 64-bit register type target (all registers have 64 bits). all 32-bits are getting promoted to 64-bit integers Problem: MUL on i32 is getting promoted to MUL on i64 MUL on i64 is getting expanded to a library call in compiler-rt the problem is that MUL32 gets promoted and then converted into a subroutine call because it is now type i64, even though I want the MUL I32 to remain as an operation in the architecture. MUL i32 would generate a 64-bit results from the lower 32-bit portions of 64-bit source operands. In customize for the operations, I am trying to do something like: case ISD::MUL: { EVT OpVT = Op.getValueType(); if (OpVT == MVT::i64) { RTLIB::Libcall LC = RTLIB::MUL_I64; SDValue Dummy; return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); } else if (OpVT == MVT::i32){ ??? What to do here to not have issues with type i32 } } I've gone a few directions on this. Defining the architecture type i32 leads to a lot of changes that I don't think is the most straightforward change. Would think there is a way to promote the MUL i32 types but still be able to "see" that as a MUL i32 somewhere down the lowering process. Are there suggestions on how to promote the type, but then be able to customize the original i64 to a call and the original mul i32 to an operation? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/5b66cabd/attachment.html>
Tom Stellard
2013-Jul-30 19:55 UTC
[LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
On Tue, Jul 30, 2013 at 01:14:16PM -0600, Dan wrote:> I'll try to run through the scenario: > > > 64-bit register type target (all registers have 64 bits). > > all 32-bits are getting promoted to 64-bit integers > > Problem: > > MUL on i32 is getting promoted to MUL on i64 > > MUL on i64 is getting expanded to a library call in compiler-rt > >Can you fix this by marking i64 MUL as Legal?> the problem is that MUL32 gets promoted and then converted into a > subroutine call because it is now type i64, even though I want the MUL I32 > to remain as an operation in the architecture. MUL i32 would generate a > 64-bit results from the lower 32-bit portions of 64-bit source operands. > > In customize for the operations, I am trying to do something like: > > case ISD::MUL: > { > EVT OpVT = Op.getValueType(); > if (OpVT == MVT::i64) { > RTLIB::Libcall LC = RTLIB::MUL_I64; > SDValue Dummy; > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > } > else if (OpVT == MVT::i32){ > > ??? What to do here to not have issues with type i32 > } > } > > > I've gone a few directions on this. > > Defining the architecture type i32 leads to a lot of changes that I don't > think is the most straightforward change. >When you say 'defining an architecture type' do you mean with addRegisterClass() in your TargetLowering constructor? If so, then this would be my recommendation. Can you elaborate more on what is preventing you from doing this.> Would think there is a way to promote the MUL i32 types but still be able > to "see" that as a MUL i32 somewhere down the lowering process. >The R600 backend does something similar to this. It has 24-bit MUL and MAD instructions and selects these by looking at an i32 integer and trying to infer whether or not it is really a 24-bit value. See the SelectI24 and SelectU24 functions in AMDGPUISelDAGToDAG.cpp. -Tom> Are there suggestions on how to promote the type, but then be able to > customize the original i64 to a call and the original mul i32 to an > operation?> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Dan
2013-Jul-31 00:56 UTC
[LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this to happen before type legalization. Right now, type legalization, promotes all MUL I32 to 64-bit, and I lose the ability to differentiate between what originally was a MUL on 64-bit and 32-bit values. Only thing that I have seen happen at DAG Selection is for lowering custom intrinsic functions like memcpy: ./Target/X86/X86SelectionDAGInfo.cpp:178:X86SelectionDAGInfo::EmitTargetCodeForMemcpy(SelectionDAG &DAG, Is there a general SelectionDAG conversion that can be made to happen before all type promotions? Again, even modifications in ISelDAGToDAG.cpp will be after type promotion in my understanding. On Tue, Jul 30, 2013 at 1:55 PM, Tom Stellard <tom at stellard.net> wrote:> On Tue, Jul 30, 2013 at 01:14:16PM -0600, Dan wrote: > > I'll try to run through the scenario: > > > > > > 64-bit register type target (all registers have 64 bits). > > > > all 32-bits are getting promoted to 64-bit integers > > > > Problem: > > > > MUL on i32 is getting promoted to MUL on i64 > > > > MUL on i64 is getting expanded to a library call in compiler-rt > > > > > > Can you fix this by marking i64 MUL as Legal? > > > the problem is that MUL32 gets promoted and then converted into a > > subroutine call because it is now type i64, even though I want the MUL > I32 > > to remain as an operation in the architecture. MUL i32 would generate a > > 64-bit results from the lower 32-bit portions of 64-bit source operands. > > > > In customize for the operations, I am trying to do something like: > > > > case ISD::MUL: > > { > > EVT OpVT = Op.getValueType(); > > if (OpVT == MVT::i64) { > > RTLIB::Libcall LC = RTLIB::MUL_I64; > > SDValue Dummy; > > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > > } > > else if (OpVT == MVT::i32){ > > > > ??? What to do here to not have issues with type i32 > > } > > } > > > > > > I've gone a few directions on this. > > > > Defining the architecture type i32 leads to a lot of changes that I don't > > think is the most straightforward change. > > > > When you say 'defining an architecture type' do you mean with > addRegisterClass() in your TargetLowering constructor? If so, then this > would be my recommendation. Can you elaborate more on what is > preventing you from doing this. > > > Would think there is a way to promote the MUL i32 types but still be able > > to "see" that as a MUL i32 somewhere down the lowering process. > > > > The R600 backend does something similar to this. It has 24-bit MUL and > MAD instructions and selects these by looking at an i32 integer and > trying to infer whether or not it is really a 24-bit value. > See the SelectI24 and SelectU24 functions in AMDGPUISelDAGToDAG.cpp. > > -Tom > > > > Are there suggestions on how to promote the type, but then be able to > > customize the original i64 to a call and the original mul i32 to an > > operation? > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/bf411901/attachment.html>
Duncan Sands
2013-Jul-31 09:33 UTC
[LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
Hi Dan, On 30/07/13 21:14, Dan wrote:> > I'll try to run through the scenario: > > > 64-bit register type target (all registers have 64 bits). > > all 32-bits are getting promoted to 64-bit integers > > Problem: > > MUL on i32 is getting promoted to MUL on i64 > > MUL on i64 is getting expanded to a library call in compiler-rt > > > the problem is that MUL32 gets promoted and then converted into a subroutine > call because it is now type i64, even though I want the MUL I32 to remain as an > operation in the architecture. MUL i32 would generate a 64-bit results from the > lower 32-bit portions of 64-bit source operands.I think you should register custom type promotion logic, see LegalizeIntegerTypes.cpp, line 40. When this gets passed a 32 bit multiplication, it should promote it to a 64 bit operation using the target specific node that does your special multiplication. Ciao, Duncan.> > In customize for the operations, I am trying to do something like: > > case ISD::MUL: > { > EVT OpVT = Op.getValueType(); > if (OpVT == MVT::i64) { > RTLIB::Libcall LC = RTLIB::MUL_I64; > SDValue Dummy; > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > } > else if (OpVT == MVT::i32){ > > ??? What to do here to not have issues with type i32 > } > } > > > I've gone a few directions on this. > > Defining the architecture type i32 leads to a lot of changes that I don't think > is the most straightforward change. > > Would think there is a way to promote the MUL i32 types but still be able to > "see" that as a MUL i32 somewhere down the lowering process. > > Are there suggestions on how to promote the type, but then be able to customize > the original i64 to a call and the original mul i32 to an operation? > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Seemingly Similar Threads
- [LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
- [LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
- [LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
- [LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64
- [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations