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.
