This is an archive of the discontinued LLVM Phabricator instance.

[ADT] Refactor comparison operator in APSInt by compareValues
AbandonedPublic

Authored by ChuanqiXu on Jan 26 2022, 10:21 PM.

Details

Summary

Now the comparison operator in APSInt would require the signedness of the operands are the same, otherwise the compiler would crash. It is really annoying that I found my code crash at A == B due to the mismatched signedness.

Then I found there is interface called compareValues which handled the mismatched signedness. So I think we should use compareValues to refactor the comparison operator. Both of them do comparison and they should have similar semantics.

Diff Detail

Event Timeline

ChuanqiXu requested review of this revision.Jan 26 2022, 10:21 PM
ChuanqiXu created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 26 2022, 10:21 PM
rjmccall requested changes to this revision.Jan 27 2022, 12:15 AM

These assertions are actually protecting against some pretty significant sources of bugs, like trying to evaluate a constant comparison without applying the appropriate conversions on the operands first. APSInt models a consistent integer type of statically-unknown width and signedness; if you're trying to use it as a possibly-negative arbitrary-precision integer, a lot of the behavior is wrong, like the fact that overflow will wrap around instead of extending the storage.

I do think it would be useful to have a type that models arbitrary-precision integer math, if you want to work on that.

This revision now requires changes to proceed.Jan 27 2022, 12:15 AM

These assertions are actually protecting against some pretty significant sources of bugs, like trying to evaluate a constant comparison without applying the appropriate conversions on the operands first. APSInt models a consistent integer type of statically-unknown width and signedness; if you're trying to use it as a possibly-negative arbitrary-precision integer, a lot of the behavior is wrong, like the fact that overflow will wrap around instead of extending the storage.

I do think it would be useful to have a type that models arbitrary-precision integer math, if you want to work on that.

I am confused about the existence of the method`compareValues`. It handles the bitwidth and signedeness. And the functionality of compareValues looks really like comparison operator to me . I think they should be consistent. If we indeed want the assertion, I think we should have one in the compareValues method.

compareValues is a specific request to do a comparison of the represented integer values. It's fine to have API like that which ignores bit-width and signedness; it doesn't change that ordinary comparisons should require no bit-width and signedness differences in order to protect against accidental mis-use.

ChuanqiXu abandoned this revision.Jan 27 2022, 5:47 PM

Oh, got it. Thanks for explanation.