https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #7) > (In reply to Aldy Hernandez from comment #6) > > You may want to look at: > > > > // Return the bitmask inherent in the range. > > > > irange_bitmask > > irange::get_bitmask_from_range () const > > { > > } > > > > IIRC, this code was originally authored by Jakub and was embedded in the > > tree-ssanames.cc code setting nonzero bits every time we set a global range. > > I just abstracted it and adapted it to work within our framework. > > I'm afraid on this testcase trying to derive bitmask from range is not going > to work if the range is that > [irange] int [-INF, -65537][-65425, -65425][111, 111][65536, +INF] > We really want to record that because of the bb we know that the low 16 bits > are equal to 111 and the upper 16 bits are unknown. > Because the range could help there only if we had a union of 65536 subranges > here. Isnt that exactly what the known bits is suppose to do? op1_range already knows [111,111] is the lower 15 bits, but it doesnt add the bitmask. We shoulod also be able to set the known mask for the lower 16 bits as well? > tree-ssanames.cc before contained just a single mask, so could only track > known zero bits vs. unknown bits rather than known zero bits vs. known one > bits vs. unknown bits. > While MASK 0xffff0000 VALUE 0x6f can represent what supposedly the > BIT_AND_EXPR optimization needs (whether we actually use it then to optimize > it away is another question). then when we see _8 = num_5(D) & 65534; the operator_bitwise_and::fold_range should pick up the known bits from the num_5 range, recognize its the only relevant part of the mask, and get it right shouldn't it? It can't do it without the mask for sure. It possible that operator_bitwise_and::fold_range needs some tweaking to recognize the known bits in op1 and map it to the mask in op2, but maybe we alreayd do that. I havent looked at that code either, but it seems like something it should be doing. So instead of _8 : [irange] int [0, 65534] MASK 0xfffe VALUE 0x0 we'd get [110,110] for _8