[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[rguenther at suse dot de]

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.