[LLVMdev] Help with promotion/custom handling of MUL i32 and MUL i64

[Tom Stellard]

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