[Bug tree-optimization/114331] Missed optimization: indicate knownbits from dominating condition switch(trunc(a))

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
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 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
from the [111, 111] range also derived from the in that case on-demand asked
MASK 0x0 VALUE 0x6f to MASK 0xffff0000 VALUE 0x6f.