<br><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 8, 2012 at 11:27 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank" class="cremed">milseman@apple.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="word-wrap:break-word"><div class="im"><blockquote type="cite">If this impacts commutativity, both the hashing and equality testing should respect it.</blockquote>
<div><br></div></div><div>Overflow should be orthogonal to commutativity. I think you're right in that hashing should respect it, so I'll mix in the overflow bits for the hash.</div></div></blockquote><div><br></div>
<div>Oh, of course. I misread that bit. Yea, just mix it in. =]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">
<div><br></div><div><blockquote type="cite">If you can't lift this logic into the operator (or instruction), maybe factor all of the commutatitivy logic? Make a static isCommutativeOp() static function, and then you can even fold the CmpInst logic into it as well?</blockquote>
</div><div><br></div></div><div>I'm not sure what's meant here. What code will be simplified by this? CmpInsts are a little different in that even "non-commutative" compares can be commuted if the predicate is swapped. In my patches, I canonicalize based on address (and swap the predicate accordingly).</div>
</div></blockquote><div><br></div><div>Yea, guess it wouldn't really help much there. LGTM.</div></div></div>