[PATCH] [PATCH][ARM] Fix issue with UMLAL (unsigned multiple accumulate long) lowering

[Matthias Braun]

Signed and unsigned multipliciation produce the same result for the lower 32 bits. The results are only different for the upper 32 bit. So I think you can just always choose UMLAL (or always SMLAL) as your transformation only accepts cases where the multiplication doesn't produce any high bits anyway.

- Matthias

> On Jun 3, 2015, at 9:11 AM, Jyoti Allur <jyoti.allur at samsung.com> wrote:
> 
> Hi Matthias,
> I have just realized that this is incorrect.
> 
>  EVT VT = MULOp.getValueType();
>      unsigned VTBits = VT.getSizeInBits();
>      FinalOpc = (VTBits & 0x8000) ? ARMISD::SMLAL : ARMISD::UMLAL;
>  }
> 
> method to choose FinalOpc is incorrect as VTBits only contains size not the actual result of MUL.
> ISD::MUL does not indicate if its signed multiply or unsigned multiply thus making it difficult to choose SMLAL or UMLAL.
> I need to be able to check if one of the operands of ISD::MUL were sign extended or not to assign SMLAL. But this information is not available in backend, it is available in DAGCombining though.Seem to have hit a roadblock, any suggestion would of help to close.
> 
> 
> REPOSITORY
>  rL LLVM
> 
> http://reviews.llvm.org/D9881
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits