[LLVMdev] [RFC] Integer Saturation Intrinsics
Herbie Robinson
hrob at curbside-recording.com
Thu Jan 15 09:40:14 PST 2015
On 1/15/15 5:51 AM, David Majnemer wrote:
>
>
> On Thu, Jan 15, 2015 at 2:33 AM, David Chisnall
> <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>
> A couple of questions:
>
> 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.
>
>
> 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).
>
> In this case, the saturating nature of the operation does not seem
> like something that can be safely ignored.
The undefined vs. wrap is a semantic difference that could affect
optimization, too. The result of the operation is undefined in one case
and well defined in the wrap case. The undefined case should allow some
code motion optimizations that they wrap case doesn't.
Algebraic transformations are affected by both wrap and saturation;
although, the saturation is more restrictive in that it affects add and
subtract while wrap would only be blocking refactoring when multiply and
divide are involved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150115/cb708b3e/attachment.html>
More information about the llvm-dev
mailing list