https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #10) > I really don't know how GORI etc. works. > But, if when the switch handling determines that _1 (the switch controlling > expression) has [irange] [111, 111] MASK 0x0 VALUE 0x6f (does it actually? > i.e. for a singleton range all the bits here are known and equal to the > value), then when trying to derive a range for related num_9(D) which is int > rather than _1's short and > _1 = (short int) num_5(D); > for the MASK/VALUE we should just use the same VALUE and or in 0xffff0000 > into MASK because we then don't know anything about the upper bits. > Though, looking at the evrp detailed dump there is > 2->3 _1 : [irange] short int [111, 111] > 2->3 _2 : [irange] int [111, 111] > 2->3 num_5(D) : [irange] int [-INF, -65537][-65425, -65425][111, > 111][65536, +INF] > and so no MASK/VALUE for any of those ranges. Right. No mask needed for _1 and _2 as the range fully represents the known bits, and operator_cast::op1_range hasn't been taught to add a bitmask when calculating num_5 yet. It could have as mask and value dded to it because its implied by the result of the cast being short int [111, 111] The routine Aldy provided should create that mask when asked I think. > Now, from comments it seems that irange_bitmask is only computed on demand > to speed things up, unless it has been explicitly set. > Now, say for _1 or _2 above, we don't have anything recorded but we can > always compute it on demand from the value range. But when adding the Which I think we are both on the same page so far. > num_5(D) range based on the related _1 range, the on-demand irange_bitmask > is no longer as precise as it would be if we when deriving that [-INF, > -65537][-65425, -65425][111, 111][65536, +INF] range We aren't deriving it from that range tho. we are solving for num_5 the equation [111,111] = (short int) num_5 The range you list is the best we can currently produce with *just* ranges. if we also add that bitmask along with the range (generated from the range on the LHS, we can adjust that to what you specify > from the [111, 111] range also derived from the in that case on-demand asked > MASK 0x0 VALUE 0x6f to MASK 0xffff0000 VALUE 0x6f. Right, so the LHS 16 bits produce MASK 0x0000 VALUE 0x6f, which means those bits should apply tot he RHS as well. Since we're extending that to 32 bits, we'd have to make the upper ones unknown, so we should be able to create num_5 : [rainge] int [-INF, -65537][-65425, -65425][111, 111][65536, +INF] MASK 0xffff0000 VALUE 0x6f And then in bb 3 when we see _8 = num_5(D) & 65534; instead of producing _8 : [irange] int [0, 65534] MASK 0xfffe VALUE 0x0 operator_bitwise_and::fold_range ought to be able to combine the known bits and come up with _8 : [irange] int [0, 65534] MASK 0x0000 VALUE 0x6e, which if Aldy's bitmask code is working right (:-) should turn into _8 : [irange] int [110, 110] It should be fairly straightforward if operator_cast::op1_range creates the mask for the range it produces.
