https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
bin.cheng <amker.cheng at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker.cheng at gmail dot com
--- Comment #4 from bin.cheng <amker.cheng at gmail dot com> ---
Before parloops, the related dump code is as below:
_469 = (unsigned long) stride.90_24;
_468 = (unsigned long) _368;
_467 = _469 * _468;
//...
_466 = _470 + _467;
_370 = (integer(kind=8)) _466;
//...
_373 = _370 + _372;
//...
# i1_1 = PHI <1(16), i1_159(24)>
_75 = (integer(kind=8)) i1_1;
_76 = _75 + _373;
*g3_77(D)[_76] = 0.0;
When analyzing scev for _370, GCC needs to handle type conversion as:
(integer(kind=8)){(unsigned long) stride.90_24 + _470, (unsigned long)
stride.90_24}
Currently GCC don't know if below scev overflows or not:
{(integer(kind=8))(unsigned long) stride.90_24 + _470,
(integer(kind=8))(unsigned long) stride.90_24}
This no-overflow information may be provided by source code declaration:
real*8 g1(f4,f3,f2,f1),g2(f4,f4,f3,f2,f1),g3(f4,f3,f2,f1)
Because the stride comes from memory layout of array "g3". But I don't see how
to compute this information and use it in SCEV.
This leads to another problem: we may be able to avoid this type conversion
here integer(kind=8) --> unsigned long --> integer(kind=8).
They are first introduced by lim2, I will investigate why.
