http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On 3/7/14 10:57 PM, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 > > --- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> --- > (In reply to Richard Biener from comment #13) >> >> Huh, adding a pre-header should _never_ do sth like that. Can you produce >> a small testcase that exhibits these kind of changes with adding/removing >> a preheader? > > I don't have a small testcase and it only shows up with -mx32. Here > is what I see. The diffs in 064t.copyprop3 are > > diff -up good/gromacs.x.064t.copyprop3 bad/gromacs.x.064t.copyprop3 > --- good/gromacs.x.064t.copyprop3 2014-03-06 13:14:22.897298915 -0800 > +++ bad/gromacs.x.064t.copyprop3 2014-03-06 13:22:00.221999369 -0800 > @@ -22774,6 +22774,7 @@ inl3300 (int & restrict nri, int[0:] * r > goto <bb 8>; > > <bb 3>: > + n_213 = 1; > > <bb 4>: > # n_8 = PHI <1(3), n_218(7)> > > n_213 is unused. There are many diffs in SSA_NAME_VERSION in 066t.vrp1. > Diffs in 082t.reassoc1 are > > diff -up good/gromacs.x.082t.reassoc1 bad/gromacs.x.082t.reassoc1 > --- good/gromacs.x.082t.reassoc1 2014-03-06 13:14:22.948297990 -0800 > +++ bad/gromacs.x.082t.reassoc1 2014-03-06 13:22:00.273998425 -0800 > @@ -24250,11 +24250,11 @@ inl3300 (int & restrict nri, int[0:] * r > float _201; > float _202; > int _206; > + float _208; > float _210; > float _211; > float _215; > float _216; > - float _242; > > <bb 2>: > _19 = *nri_18(D); > @@ -24403,8 +24403,8 @@ inl3300 (int & restrict nri, int[0:] * r > ff_152 = _155 + fp_147; > vnb12_153 = vv_149 * c12_116; > fijr_154 = ff_152 * c12_116; > - _242 = vnb12_153 + vnb6_134; > - vnbtot_156 = _242 + vnbtot_11; > + _208 = vnb12_153 + vnb6_134; > + vnbtot_156 = _208 + vnbtot_11; > _157 = fijd_135 + fijc_109; > _158 = _157 + fijr_154; > _159 = ((_158)); > > When it gets to 089t.sincos, diffs are > > diff -up good/gromacs.x.089t.sincos bad/gromacs.x.089t.sincos > --- good/gromacs.x.089t.sincos 2014-03-06 13:14:22.967297646 -0800 > +++ bad/gromacs.x.089t.sincos 2014-03-06 13:22:00.291998098 -0800 > @@ -24252,14 +24252,14 @@ inl3300 (int & restrict nri, int[0:] * r > float _201; > float _202; > int _206; > + float _208; > float _210; > float _211; > + float powmult_213; > float _215; > float _216; > - float powmult_238; > - float powmult_240; > - float powmult_241; > - float _242; > + float powmult_243; > + float powmult_244; > > powmult_xxx are created by make_temp_ssa_name (type, NULL, "powmult") > in tree-ssa-math-opts.c for > > rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; > > Different powmult_xxx have nothing to do with each others. The orders of > powmult SSA_NAME_VERSION are different. As the result, sort_by_operand_rank > sorts them differently and diffs in 125t.reassoc2 are > > powmult_80 = dx11_70 * dx11_70; > - powmult_241 = dy11_71 * dy11_71; > - powmult_240 = dz11_72 * dz11_72; > - _699 = powmult_240 + powmult_80; > - rsq11_77 = _699 + powmult_241; > + powmult_213 = dy11_71 * dy11_71; > + _75 = powmult_213 + powmult_80; > + powmult_244 = dz11_72 * dz11_72; > + rsq11_77 = _75 + powmult_244; > > This is > > rsq11 = dx11*dx11+dz11*dz11+dy11*dy11; > > vs > > rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; > > For FP operations, they may generate slightly different results. > It shows the reassoc pass is unstable, depending on FREE_SSANAMES when > make_temp_ssa_name is called. The question is why that all is dependent on whether we add/remove preheaders. That shouldn't create any new SSA names or remove existing ones. Yes, maybe sort_by_operand_rank shouldn't sort by SSA_NAME_VERSION but by existing gimple_uid of the definition stmt (so try to preserve stmt order). But that's a completely unrelated thing.
