https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 20 Nov 2014, ppalka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986 > > --- Comment #5 from ppalka at gcc dot gnu.org --- > (In reply to Richard Biener from comment #3) > > Ok, now already existing forwprop code gets fed with > > > > <bb 2>: > > _3 = a_2(D) == 0; > > x_4 = (char) _3; > > _7 = ~_3; > > _8 = (int) _7; > > MEM[(int *)d_5(D) + 8B] = _8; > > if (x_4 != 0) > > > > where we now in the first forwprop pass identified the opportunity > > to use ~_3 instead of x_4 == 0 thus x_4 is now no longer multi-use. > > This makes us optimize if (x_4 != 0) to if (_3 != 0) which we > > re-optimize in fold_gimple_cond now to '_3' and then of course > > if (_3 != 0) (err, and we return "changed"....) which means we > > now propagate _again_ via forward_propagate_into_gimple_cond > > which now specifically allows aggressive forwarding of compares, > > bypassing single-use restrictions. See > > > > 2014-11-16 Patrick Palka <ppa...@gcc.gnu.org> > > > > PR middle-end/63790 > > * tree-ssa-forwprop.c (forward_propagate_into_comparison_1): > > Always combine comparisons or conversions from booleans. > > > > thus me fixing my "mistake" does not help anymore. > > I worried that such an issue might pop up... > > If you think my patch should be reverted, note that there is a more benign > version of the patch here > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00963.html (which still fixes > the > test case I was originally interested in fixing). No, I think that conceptually aggressive forwarding into if conditions is wanted. I believe it's not impossible to fix the very special cases that might pop up - usually it will help code generation. Richard.