<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 1/15/15 5:51 AM, David Majnemer
wrote:<br>
</div>
<blockquote
cite="mid:CAL7bZ_cL48gra4OiUwwEdbExVaoMK8x-b63h9Y94R7N754ANBw@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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>
</div>
</blockquote>
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. <br>
<br>
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. <br>
<br>
</body>
</html>