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

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

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

--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I think y'all have it all figured out.  Basically,

operator_cast::op1_range() is solving num_5 in the equation:

[111,111] = (short int) num_5

Where lhs is:
(gdb) p debug(lhs)
[irange] short int [111, 111]

And the bitmask is implicit, but correctly calculated:
(gdb) p debug(lhs.get_bitmask ())
MASK 0x0 VALUE 0x6f

And the range for num_5 is just varying.

You are looking at the true side of the truncating_cast_p() conditional in
op1_range.  Essentially, once it starts building the range it ignores known
bitmasks, which cause it to return an overly conservative range.

And yes, bitmasks are calculated on demand per the comment in get_bitmask:

  // The mask inherent in the range is calculated on-demand.  For               
  // example, [0,255] does not have known bits set by default.  This            
  // saves us considerable time, because setting it at creation incurs          
  // a large penalty for irange::set.  At the time of writing there             
  // was a 5% slowdown in VRP if we kept the mask precisely up to date          
  // at all times.  Instead, we default to -1 and set it when                   
  // explicitly requested.  However, this function will always return           
  // the correct mask.                                

We may have to revisit this.  Perhaps it doesn't matter any more, and we could
keep bitmasks up to date.  It would definitely make the dumps easier to read. 
Though, at least for this testcase the bitmask is correctly returned with
get_bitmask().

I think the analysis in comment 11 is spot on.  And no Andrew, it's not *my*
code, it all comes from the bit-ccp code :-P.

fold_range() should call update_bitmask(), which eventually calls
bit_value_binop() in the CCP code.

And yes Jakub, as you have noticed, BIT_IOR_EXPR, BIT_XOR_EXPR, and likely
other operators may need to be tweaked to take bitmasks into account.  I
wouldn't be surprised if there's a lot of low hanging fruit in this space.