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.
