On Thu, Aug 03, 2017 at 11:29:44AM -0500, Bill Schmidt wrote: > > And, wouldn't it be more readable to use: > > && (TYPE_UNSIGNED (target_type) > > ? (wi::eq_p (bump, wi::zext (bump, prec)) > > || wi::eq_p (bump + wi::to_widest (maxval) + 1, > > wi::zext (bump, prec))) > > : wi::eq_p (bump, wi::sext (bump, prec))) > > ? > > Probably. As noted, it's all becoming a bit unreadable with too > much negative logic in a long conditional, so I want to clean that > up in a follow-up. > > > For TYPE_UNSIGNED, do you actually need any restriction? > > What kind of bump values are wrong for unsigned types and why? > > If the value of the bump is actually larger than the precision of the > type (not likely except for quite small types), say 2 * (maxval + 1) > which is congruent to 0, the replacement is wrong.
Ah, ok. Anyway, for unsigned type, perhaps it could be written as: && (TYPE_UNSIGNED (target_type) ? wi::eq_p (wi::neg_p (bump) ? bump + wi::to_widest (maxval) + 1 : bump, wi::zext (bump, prec)) : wi::eq_p (bump, wi::sext (bump, prec))) I mean, if bump >= 0, then the bump + wi::to_widest (maxval) + 1 value has no chance to be equal to zero extended bump, and for bump < 0 only that one has a chance. Jakub