[cfe-dev] Why no NSW/NUW with SHL instruction?

David Majnemer david.majnemer at gmail.com
Fri Nov 21 12:12:33 PST 2014


On Fri, Nov 21, 2014 at 10:00 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> So why in some cases does it still produce the nsw/nuw flag? Just curious.
>

Let's say you had:
%mul = mul nsw i32 %V, 2

This can safely be transformed into:
%mul = shl nsw i32 %V, 1

However, let's take the example:
%mul = mul nsw i32 %V, -2147483648

We cannot transform this into:
%mul = shl nsw i32 %V, 31

If we did this, then we would have created a poison value where non
previously existed.
This is because when %V is 1, 1 * -2147483648 is just -2147483648 but 1 <<
31 violates NSW.

Instead, we end up with:
%mul = shl i32 %V, 31

I don't think it's correct to see 'shl nsw' as an arithmetic left-shift and
'shl nuw' as a logical shift.
Where would that leave 'shl nsw nuw' ?

Finally, nsw and nuw flags are permitted to be ignored or otherwise dropped
when optimizing or performing analysis.


>
> We are going with intrinsics, but I'm still curious. Thanks.
>
> On Fri, Nov 21, 2014 at 12:54 PM, David Chisnall <
> David.Chisnall at cl.cam.ac.uk> wrote:
>
>> On 21 Nov 2014, at 17:39, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>
>> > I don't care if clang only produces shl, I'm more curious how to get
>> the signed info to the backend for shl when it's not producing a nsw/nuw
>> flag? I'm currently not sure how this would be done, is there another arch
>> that manages this somehow?
>>
>> I think the point is that the only difference between the two is the
>> overflow flag, which is not something that C exposes, and LLVM IR tends to
>> be driven by the needs of the front ends.
>>
>> If you wanted an IR instruction that represented a left shift that set a
>> flag, then you'd need something that returned both the result and the
>> overflow flag (look at the existing overflow checked addition intrinsics
>> for inspiration).  This sort of thing tends only to be added when someone
>> needs it.  If the first someone to need it is you, then... patches
>> welcome.  I think that you'd probably want to implement it as a
>> shift-with-overflow intrinsic rather than a variation on the shl
>> instruction and you'd probably need to provide some expansion for it for
>> processors that don't have a direct mapping.
>>
>> David
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141121/45611fb4/attachment.html>


More information about the cfe-dev mailing list