>>> tem = (char) 255 + (char) 1; >>> >>> which has a value-range of [0,0] but clearly when computed in >>> SImode the value-range is [256, 256]. That is, VRP computes >>> value-ranges in the expression type, not in some arbitrary >>> larger type. >>> >>> So what you'd have to do is take the value-ranges of the >>> two operands of the plus and see whether the plus can overflow >>> QImode when computed in SImode (for the example). >>> Ok, I will handle it as you have suggested here.
> Not sure if I understand what you are saying here. As for the above > case > >>> tem = (char) 255 + (char) 1; > > tem is always of type 'char' in GIMPLE (even if later promoted > via PROMOTE_MODE) the value-range is a 'char' value-range and thus > never will exceed [CHAR_MIN, CHAR_MAX]. The only way you can > use that directly is if you can rely on undefined behavior > happening for signed overflow - but if you argue that way you > can simply _always_ drop the (sext:SI (subreg:QI part and you > do not need value ranges for this. For unsigned operations > for example [250, 254] + [8, 10] will simply wrap to [3, 7] > (if I got the math correct) which is inside your [CHAR_MIN + 1, > CHAR_MAX - 1] but if performed in SImode you can get 259 and > thus clearly you cannot drop the (zext:SI (subreg:QI parts. > The same applies to signed types if you do not want to rely > on signed overflow being undefined of course. > Thanks for the explanation. I now get it and I will rework the patch. Thanks, Kugan
