<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 18, 2012, at 6:16 PM, Richard Trieu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Wed, Jul 18, 2012 at 11:19 AM, 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 class="HOEnZb"><div class="h5">On Wed, Jul 18, 2012 at 11:12 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div class="h5">
<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><div><div><div>On Jul 18, 2012, at 2:28 AM, Chandler Carruth wrote:</div>
<blockquote type="cite">On Tue, Jul 17, 2012 at 11:47 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>On Tue, Jul 17, 2012 at 11:26 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I find the definition of APInt's operator== deeply troubling. Why *assert* if the bit widths aren't equal? That doesn't make a lot of sense to me. The function that it calls to actually implement it turns around and considers mismatched bitwdiths to cause *inequality*.</div>
<div><br></div><div>However it seems that there is a very simple definition of equality we could use instead: zero-extended equality for APInt, and sign-extended equality for APSInt. I wonder if there would be general support for making APInt::operator== and APSInt::operator== work in this more rational model...</div>
</blockquote><div><br></div></div><div>APInt has no knowledge of whether its high bit is a sign bit, so always zero-extending will be wrong in the case where it is in fact a sign bit. APSInt does know this, so if we want to support heterogenous comparisons, we should sign-extend if the APSInt is signed, and zero-extend if it is unsigned. Heterogenous comparison on APInt is fundamentally unsafe, so asserting there seems reasonable to me.</div>
</div></blockquote><div><br></div><div>Well, Nick's comment may obviate the extension question, which leaves us with a simpler problem of comparing the same sizes for equality or inequality. I don't actually see any problems comparing same-sized APInts and APSInts for equality or inequality as-if they were both APInts. Given two APSInts, I think that the signedness should participate in the equality test though...</div>
</div></div></blockquote></div><br></div></div><div>It seems silly for APInt to treat bitwidth inequality as an illegal operation but APSInt to treat it as a semantic difference. APInt's assertions *do* find bugs; I would much rather extend those to APSInt than have it forge a new contract.</div>
</div></blockquote><div><br></div></div></div><div>I never intended to suggest inconsistency between the two. I just didn't understand the motivation for the assertion even at the APInt layer. Nick provided that though, which was all I needed. =] </div>
</div></div>
<br></blockquote><div>New patch. Switched int parameters to int64_t. APSInt::operator!= now refers to APSInt::operator== </div></div>
</blockquote><br></div><div>LGTM, thanks!</div><div><br></div><div>-Chris</div><br></body></html>