[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 17 Aug 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> --- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
> Created attachment 41993
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41993&action=edit
> Patch to reduce the problem
> 
> Can be reduced by given patch. The function is called for following loop:
> 
>   <bb 45>:
>   # b_118 = PHI <b_424(28), b_75(56)>
>   # count.30_122 = PHI <count.30_38(28), count.30_76(56)>
>   c = 0.0;
>   if (le.52_14 <= 0)
>     goto <bb 37>;
>   else
>     goto <bb 29>;
> 
>   <bb 29>:
>   _253 = le.52_14 + -1;
>   if (le.52_14 < _253)
>     goto <bb 37>;
>   else
>     goto <bb 30>;
> 
>   <bb 30>:
>   _256 = le.52_14 * 2;
>   if (_256 < -1)
>     goto <bb 37>;
>   else
>     goto <bb 31>;
> 
>   <bb 31>:
>   k2_262 = le.52_14 + 1;
>   _269 = _253 + k2_262;
>   j02_270 = _269 + 1;
>   j04_275 = _269 + 2;
>   M.0_403 = MIN_EXPR <_253, 0>;
>   mo_278 = M.0_403 + 1;
>   M.1_391 = MIN_EXPR <k2_262, 0>;
>   if (k2_262 < 0)
>     goto <bb 32>;
>   else
>     goto <bb 33>;
> 
>   <bb 32>:
>   m_280 = 1 - M.1_391;
> 
>   <bb 33>:
>   # m_281 = PHI <1(31), m_280(32)>
>   if (mo_278 < m_281)
>     goto <bb 37>;
>   else
>     goto <bb 34>;
> 
>   <bb 34>:
>   _284 = fak[0];
>   _285 = _284 - 2.99573230743408203125e+0;
>   _286 = (integer(kind=8)) j02_270;
>   _287 = _286 + -1;
>   _288 = fak[_287];
>   _289 = _285 + _288;
>   _293 = _284 + _289;
>   _294 = (integer(kind=8)) j04_275;
>   _295 = _294 + -1;
>   _296 = fak[_295];
>   del_297 = _293 - _296;
>   j6_299 = le.52_14 + 2;
>   j7_301 = le.52_14 + 2;
>   _308 = _284 + del_297;
>   _313 = _284 + _308;
>   _315 = (integer(kind=8)) le.52_14;
>   _316 = _315 + -1;
>   _317 = fak[_316];
>   _318 = _313 + _317;
>   _319 = (integer(kind=8)) j6_299;
>   _320 = _319 + -1;
>   _321 = fak[_320];
>   _322 = _318 + _321;
>   _323 = (integer(kind=8)) j7_301;
>   _324 = _323 + -1;
>   _325 = fak[_324];
>   _326 = _322 + _325;
>   _330 = _317 + _326;
>   _331 = ((_330));
>   sym_332 = _331 * 5.0e-1;
> 
>   <bb 35>:
>   # k_333 = PHI <m_281(34), k_369(57)>
>   j2_335 = k2_262 + k_333;
>   _336 = -k_333;
>   j3_337 = 2 - k_333;
>   j4_339 = 2 - k_333;
>   _340 = _253 - k_333;
>   j5_341 = _340 + 2;
>   _342 = (integer(kind=8)) k_333;
>   _343 = _342 + -1;
>   _344 = fak[_343];
>   _345 = sym_332 - _344;
>   _349 = _345 - _344;
>   _350 = (integer(kind=8)) j2_335;
>   _351 = _350 + -1;
>   _352 = fak[_351];
>   _353 = _349 - _352;
>   _354 = (integer(kind=8)) j3_337;
>   _355 = _354 + -1;
>   _356 = fak[_355];
>   _357 = _353 - _356;
>   _358 = (integer(kind=8)) j4_339;
>   _359 = _358 + -1;
>   _360 = fak[_359];
>   _361 = _357 - _360;
>   _362 = (integer(kind=8)) j5_341;
>   _363 = _362 + -1;
>   _364 = fak[_363];
>   _365 = _361 - _364;
>   _366 = __builtin_expf (_365);
>   _367 = c;
>   _368 = _366 - _367;
>   c = _368;
>   k_369 = k_333 + 1;
>   if (mo_278 == k_333)
>     goto <bb 36>;
>   else
>     goto <bb 57>;
> 
>   <bb 57>:
>   goto <bb 35>;
> 
>   <bb 36>:
>   _370 = _253 + k_333;
>   _371 = _370 + 1;
>   _372 = _371 << 1;
>   _373 = _372 & 2;
>   _374 = 1 - _373;
>   _375 = (real(kind=4)) _374;
>   _377 = _368 * _375;
>   c = _377;
> 
>   <bb 37>:
>   c.58_18 = c;
>   b_75 = c.58_18 + b_118;
>   count.30_76 = count.30_122 + -1;
>   if (count.30_76 <= 0)
>     goto <bb 38>;
>   else
>     goto <bb 56>;
> 
>   <bb 56>:
>   goto <bb 45>;
> 
> where we return true for 'c'. The function's comment:
> 
>  /* Returns true if REF is independent on all other memory references in
>    LOOP.  */
> 
> which is probably wrong as there are various memory references that influence
> value of the 'c'.

Not in the above code?  Well, direct accesses of c obviously.

I will have a look.

> I have very small experience in loop optimizations, thus leaving to somebody
> more skilled.
> 
>