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

Matthias Braun matze at braunis.de
Wed Jun 3 11:07:47 PDT 2015


Your example performs a 32bit multiplication with a 32bit result (which is then extended to 64bit for the addition). This means only the lower 32bit of the multiplication result are used, those lower 32bit are the same with signed or unsigned multiplication.

You need to have examples like the following where the multiplication produces an actual 64bit result to have signedness matter:
long long foo(long long a, int b, int c) {
    return a + (long long)b * (long long)c;
}
unsigned long long bar(unsigned long long a, unsigned b, unsigned c) {
    return a + (unsigned long long)b * (unsigned long long)c;
}

- Matthias

> On Jun 3, 2015, at 10:01 AM, Jyoti Rajendra Allur <jyoti.allur at samsung.com> wrote:
> 
> Hi Matthias,
> Thanks a lot for your reply. 
> What about in this case which I was trying to handle in addition to those mentioned previously in review. 
> 
> long long
> foo (long long a, int b, int c)
> {
>  return a + b * c;
> }
> This is a signed multiplication resulting in a 64 bit value isn't ? How do we choose SMLAL or UMLAL
> I was under the impression that if either of the mul operands is a signed valued and added to a long value then select SMLAL, if both operands of mul are unsigned then select UMLAL.
> Is the UMLAL/SMLAL selected based on the result value after adding the long value ?
> 
> Regards,
> Jyoti Allur
> 
> ------- Original Message -------
> Sender : Matthias Braun<matze at braunis.de> 
> Date   : Jun 03, 2015 21:55 (GMT+05:30)
> Title  : Re: [PATCH] [PATCH][ARM] Fix issue with UMLAL (unsigned multiple
> accumulate long) lowering
> 
> 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
> 
> <p> </p><p> </p>
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits





More information about the llvm-commits mailing list