<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 2:33 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A couple of questions:<br>
<br>
1) Should this really be an intrinsic and not a flag on add?  The add instruction already allows overflow to be either undefined or defined to wrap.  Making it defined to saturate seems a natural extension.<br></blockquote><div><br></div><div>I don't think this should be a flag on add.  Flags are designed such that the middle-end may be ignorant of them and nothing bad might happen, it is always safe to ignore or drop flags when doing so is convenient (for a concrete example, take a look at reassociate).</div><div><br></div><div>In this case, the saturating nature of the operation does not seem like something that can be safely ignored.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) How do you imagine this being used and what are the guarantees for sequences of operations with respect to optimisation?  If I do a+b-c (or +c where c is negative), and a+b would saturate, but a+(b-c) would not, then is it allowed for an optimiser to generate the second rather than the first?  If it's an intrinsic that's opaque to optimisers, then that's not a problem for correctness, but then you'll miss some potentially beneficial optimisations.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On 14 Jan 2015, at 22:08, Ahmed Bougacha <<a href="mailto:ahmed.bougacha@gmail.com">ahmed.bougacha@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> The patches linked below introduce a new family of intrinsics, for<br>
> integer saturation: @llvm.usat, and @llvm.ssat (unsigned/signed).<br>
> Quoting the added documentation:<br>
><br>
>      %r = call i32 @llvm.ssat.i32(i32 %x, i32 %n)<br>
><br>
> is equivalent to the expression min(max(x, -2^(n-1)), 2^(n-1)-1), itself<br>
> implementable as the following IR:<br>
><br>
>      %min_sint_n = i32 ... ; the min. signed integer of bitwidth n, -2^(n-1)<br>
>      %max_sint_n = i32 ... ; the max. signed integer of bitwidth n, 2^(n-1)-1<br>
>      %0 = icmp slt i32 %x, %min_sint_n<br>
>      %1 = select i1 %0, i32 %min_sint_n, i32 %x<br>
>      %2 = icmp sgt i32 %1, %max_sint_n<br>
>      %r = select i1 %2, i32 %max_sint_n, i32 %1<br>
><br>
><br>
> As a starting point, here are two patches:<br>
> - <a href="http://reviews.llvm.org/D6976" target="_blank">http://reviews.llvm.org/D6976</a>  Add Integer Saturation Intrinsics.<br>
> - <a href="http://reviews.llvm.org/D6977" target="_blank">http://reviews.llvm.org/D6977</a>  [CodeGen] Add legalization for<br>
> Integer Saturation Intrinsics.<br>
><br>
> From there, we can generate several new instructions, more efficient<br>
> than their expanded counterpart.  Locally, I have worked on:<br>
> - ARM: the SSAT/USAT instructions (scalar)<br>
> - AArch64: the SQ/UQ ADD/SUB AArch64 instructions (vector/scalar<br>
> saturating arithmetic)<br>
> - X86: PACK SS/US (vector, saturate+truncate)<br>
> - X86: PADD/SUB S/US (vector, saturating arithmetic)<br>
><br>
> Anyway, let's first agree on the intrinsics, so that further<br>
> development is done on trunk.<br>
><br>
> Thanks!<br>
> -Ahmed<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>