<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 12, 2014 at 5:50 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">On Thu, Jun 12, 2014 at 5:22 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">1. All cmpxchg instructions now return { iN, i1 } where the first<br>

value is what we got before (the loaded result), the second == 1 if an<br>
exchange took place.</div></blockquote></div><br></div>Having to do extractvalue to get stuff out of these kinds of aggregates is... somewhat horrible... have you thought of any alternatives?</blockquote></div><br>Having thought about this a bit, I don't see anything better.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">If we lived in a world w/o the select instruction, there might be a better design for this (and for the overflow observing arithmetic intrinsics).</div><div class="gmail_extra">

<br></div><div class="gmail_extra">It is a bit sad, especially because I can't see a good reason to make the weak variant an intrinsic and force this through the call path...</div><div class="gmail_extra"><br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">going back to the meat of the proposal...</div></div>