[cfe-commits] [llvm-commits] [Patch] Update to APSInt

[Richard Smith]

On Tue, Jul 17, 2012 at 11:26 PM, Chandler Carruth <chandlerc at google.com>wrote:
>
> 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*.
>
> 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...
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120717/8f44830d/attachment.html>