llvm dev - Jul 2013 - [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>

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

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>

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
>