[llvm-commits] [Patch] Update to APSInt

[Chandler Carruth]

Why assert if the signs don't match? I would expect the operator== to
simply return false if the signs don't match...

Why only accept 'int'? The APInt underlying system naturally would support
int64_t.

Why use isSameValue()? To be consistent with APInt's operators, you
shouldn't support zero-extending.

I would test for sign, handle than, and then explicitly delegate to
APInt::operator==

Then for operator!=, I would implement it directly in terms of negating
operator==.


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...


On Tue, Jul 17, 2012 at 4:04 PM, Richard Trieu <rtrieu at google.com> wrote:

> This patch adds missing operator== and operator!= to APSInt.  Currently,
> comparing two APSInt's will compare them with APInt's operator==, which
> does not check signedness.  This may lead to a problem where a large
> unsigned APSInt will equal a negative APSInt, such as -1 and 0xffff.
>
> One patch is to LLVM to add the functions.  The other is to fix up the
> uses in Clang.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120717/6629166a/attachment.html>