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

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 7 Sep 2016, avieira at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
> 
> --- Comment #7 from avieira at gcc dot gnu.org ---
> if-convert is a no go here, for the reason Andrew pointed out, sorry missed
> that comment!
> 
> 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.

> The fact is that for the code-hoisting to work here, the pseudo for r112 has to
> be shared among both code-paths, so unless you add an extra move:
> 
> BB0:
> r112:SI = r0:SI
> 
> BB 1:
> ...
> r116:SI=r112:SI 0>>0x1
> rNEW:SI=zero_extend(r116:SI#0)
> ...
> if CC goto BB2 else BB Extra
> BB 2:
> r127:SI=rNEW:SI^r129:SI
> r112:SI=zero_extend(r127:SI#0)
> if LOOP: goto BB1 else BB exit
> BB EXTRA:
> r112:SI=rNEW:SI
> if LOOP: goto BB1 else BB exit
> 
> 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.