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

[Dan]

Thanks Tom.  I really appreciate your insight.

I'm able to use the customize to get the 64-bit to go to a subroutine and
for the 32-bit, I am generate XXXISD::MUL32.  I'm not sure then what you
mean about "overriding" the ReplaceNodeResults.

For ReplaceNodeResults, I'm doing:

 SDValue Res = LowerOperation(SDValue(N, 0), DAG);

  for (unsigned I = 0, E = Res->getNumValues(); I != E; ++I)
    Results.push_back(Res.getValue(I));

I did have to put in the following as well:

           SDValue LHS = Op.getOperand(0);
            SDValue RHS = Op.getOperand(1);
            LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS);
            RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS);
            return DAG.getNode(XXXISD::MUL32, Op->getDebugLoc(), MVT::i64,
LHS, RHS);

In order to get the operation to be able to be able to go forward and match
the new operation with the input operands (which were still I32 and not yet
type-legalized to i64).  Does this make sense to you?


Here's what I am using to generate the XXXISD::MUL32:

  if(OpVT != MVT::i64) {
            //Op.getNode()->dumpr();

            SDValue LHS = Op.getOperand(0);
            SDValue RHS = Op.getOperand(1);
            LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS);
            RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS);

            return DAG.getNode(XXXISD::MUL32, Op->getDebugLoc(), MVT::i64,
LHS, RHS);
          }
Not sure if the above is correct?

It is then running into a problem with the next ADD instruction not being
able to PromoteIntRes_SimpleIntBinOp, it tries to check the XXXISD::MUL32

(gdb) p N->dumpr()
0x23ad0d0: i32 = add [ID=0] 0x23aff60, 0x23acfd0
  0x23aff60: i64 = <<Unknown Node #192>> [ID=-3] 0x23b0260, 0x23b0160
    0x23b0260: i64 = and [ID=-3] 0x23af660, 0x23b0060: i64 =
Constant<4294967295> [ID=-3]
      0x23af660: i64,ch = load<LD4[@i], anyext from i32> [ID=-3] 0x238b068:
ch = EntryToken [ID=-3], 0x23ac7d0: i64 = GlobalAddr\
ess<i32* @i> 0 [ID=-3], 0x23ac9d0: i64 = undef [ID=-3]
    0x23b0160: i64 = and [ID=-3] 0x23afc60, 0x23b0060: i64 =
Constant<4294967295> [ID=-3]
      0x23afc60: i64,ch = load<LD4[@j], anyext from i32> [ID=-3] 0x238b068:
ch = EntryToken [ID=-3], 0x23acbd0: i64 = GlobalAddr\
ess<i32* @j> 0 [ID=-3], 0x23ac9d0: i64 = undef [ID=-3]
  0x23acfd0: i32,ch = load<LD4[@k]> [ID=-3] 0x238b068: ch = EntryToken
[ID=-3], 0x23aced0: i64 = GlobalAddress<i32* @k> 0 [ID=-3\
], 0x23ac9d0: i64 = undef [ID=-3]




When you say that I'll have to take care of the node elsewhere, does that
mean in defining it as a proper way to lower? Like below?  I found that if
I don't then put the XXXISD::MUL32 in the LowerOperation, then after it is
created doing the custom change of MUL, that it just dies not knowing how
to lower the machine op. I would have thought that there was a default path
for any XXXISD operation?  And I didn't see other Targets generating their
machine ops

SDValue XXXTargetLowering::
LowerOperation(SDValue Op, SelectionDAG &DAG) const {

  case XXXISD::MUL32:
    return SDValue();


Really appreciate your help and any other pointers.

Dan



On Wed, Jul 31, 2013 at 12:38 AM, Tim Northover <t.p.northover at gmail.com>wrote:

> Hi Dan,
>
> If you set the node's action to "Custom", you should be able to
> interfere in the type legalisation phase (before it gets promoted to a
> 64-bit MUL) by overriding the "ReplaceNodeResults" function.
>
> You could either expand it to a different libcall directly there, or
> replace it with a target-specific node (say XXXISD::MUL32) which
> claims to take i64 types but you really know is the 32-bit multiply.
> Then you'd have to take care of that node elsewhere, of course.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/78a87e81/attachment.html>