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