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

[Matthias Braun]

In http://reviews.llvm.org/D9881#176316, @jyoti.allur wrote:

> Hi Matthias,
>  To clarify, Constant, SRA, CopyFromReg are possible input nodes to ADDE node.


Hmm, why would you need to restrict the possible nodes here? My understanding is that UMLAL does a full 64bit addition, so I don't see why you would need to restrict those.

> I was trying to cover cases where ISD::MUL, ISD::ADDC, ISD::ADDE can be combined to a S/UMLAL where in ISD::MUL operands are less 8-bit or 16-bits operands. In these cases result can stored in a in single 32-bit register. Hence in such cases, none of ADDE 's operand will store result from ISD:MUL. Instead, one of the ADDE's operand will hold 32:63 bits of 64-bit accumulate value, while the 0:31 bits of the accumulate value is stored in one of the operands of ADDC.

> 

> for example: in the assembly below, 

>  R1 - ACC [ 32:63 ] 

>  R0 - ACC [ 0:31 ]

> 

>   foo:

>           ldrb    r2, [r2]

>           ldrh    r3, [r3]

>           mul     r2, r3, r2

>           adds    r0, r2, r0

>           adc     r1, r1, #0

>           bx      lr

> 

> 

> I agree, overflow cases were not handled yet. Could you suggest how to detect overflow ?


Well you need to match patterns that are obviously fine and reject everything else.

Good things would probably be querying for the NoUnsignedWrap flag, or using SelectionDAG::computeKnownBits and test if both MUL operands have their upper 16bit known to be zero. One can probably think of more patterns so I'd factor it out into a function so people can add more patterns later.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D9881

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/