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

[Nick Lewycky]

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

This is a design principle across APInt, the assumption that bitwidths 
are the same across any two APInt's you do two operations with. It makes 
sense when you're thinking about x.contains(y) or intersection or 
whathaveyou, but it's pretty surprising if you're coming in from the 
context of C++ containers.

A concise way to think about it is that it's a dynamically checked type 
property, like 'icmp eq i32 0 == i8 0' is invalid.

Nick

  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
> <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits