[Bug rtl-optimization/77499] [7 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range

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

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

--- Comment #9 from avieira at gcc dot gnu.org ---

> > So I dont know... Only thing I can think of is better "value-range"-like
> > analysis for combine, but that might be too costly?
> 
> So we are not really looking for combine to combine the shift stmt
> with the xor stmt?  Because combine doesn't consider that because of
> the multi-use.

AFAIK, combine will not combine the shift and xor because they are in different
basic blocks. The multi-use prevents it from tracking the origin of r112 back
to a point where it knows that it its higher bits are all 0.

> > 
> > And you end up with an extra move rather than a zero_extend. But maybe the move
> > can be optimized away in later stages? Or maybe put in the same conditional
> > execution block as the XOR...
> 
> Well, we run into a general issue of the RTL combiner -- fwprop and
> ree are other passes that are supposed to remove extensions in some
> cases.
> 
> Really, the user could have written the code in a way CSEing the
> shift himself -- it's unfortunate that we now fail to optimize the
> non-CSEd source but that can only be a reason to enhance downstream
> passes.

True, if say the unused 'y' I left in there for some odd reason were used to
CSE (x >> 1) outside the if-then-else, then you would end up with the
zero_extend in both -fcode-hoisting and -fno-code-hoisting.