Hi Chris, Frits,<div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> I think that Owen is the best one to handle this.  In addition to handling the signed versions of these as well, does this correctly handle the case when the subtract comes first, and the cases when the overflow bit is actually used?<br>



<br>
</div>I don't see any issues with the use/non-use of the overflow bit.  For the signed overflow versions, is it only the semantics of the overflow bit that are affected?  Is the value part of the result the same between sadd/uadd?</blockquote>


<div><br></div><div>Yep - use/non-use of the overflow bit should be a non-issue with this patch.</div><div><br></div><div>Regarding the signed intrinsics: I've stayed conservative with this patch. I haven't checked the signed intrinsics yet to address Owen's question (do the semantics of the value parts change?). I'll try to find time for that tomorrow.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> In principle, we'd want to optimize:<br>
><br>
> a = add i32 y, z<br>
> ...<br>
> b,c = addo(y,z)<br>
><br>
> into:<br>
><br>
> b,c = addo(y,z)<br>
> a = b<br>
</div>> …<br>
<br>
I don't think this patch will currently do this.</blockquote><div><br></div><div>No: This case won't be caught by my patch.</div><div><br></div><div>Committed on Owen's advice in r134677.</div><div><br></div>
<div>Cheers,</div><div>Lang.</div></div></div>