[Bug fortran/83017] DO CONCURRENT not parallelizing
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Nov 16 11:52:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We fail to analyze dependeces here
Considering loop 6
loop is innermost
Creating dr for MEM[(real(kind=4)[0:D.3539] *)&A.7][_85]
analyze_innermost: Applying pattern match.pd:84, generic-match.c:11356
failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7]
Access function 0: scev_not_known;
Creating dr for MEM[(real(kind=4)[0:D.3539] *)&A.7][_85]
analyze_innermost: Applying pattern match.pd:84, generic-match.c:11356
failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7]
Access function 0: scev_not_known;
(compute_affine_dependence
stmt_a: _90 = MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
stmt_b: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85] = _99;
Data ref a:
#(Data Ref:
# bb: 7
# stmt: _90 = MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
# ref: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
# base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7];
# Access function 0: scev_not_known;
#)
Data ref b:
#(Data Ref:
# bb: 7
# stmt: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85] = _99;
# ref: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
# base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7];
# Access function 0: scev_not_known;
#)
affine dependence test not usable: access function not affine or constant.
) -> dependence analysis failed
...
this is because
k = mod( j, nsplit ) + 1
makes the k index not an affine function.
<bb 7> [85.00%]:
# j_205 = PHI <_87(8), _82(6)>
_85 = j_205 % 4;
_87 = j_205 + 1;
_90 = MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
_91 = _87 << 1;
_92 = _91 & 2;
_93 = 1 - _92;
_94 = (real(kind=4)) _93;
_95 = j_205 * 2;
_96 = _95 + -1;
_97 = (real(kind=4)) _96;
_98 = _94 / _97;
_99 = _90 + _98;
MEM[(real(kind=4)[0:D.3539] *)&A.7][_85] = _99;
if (_83 < _87)
goto <bb 10>; [15.00%]
else
goto <bb 8>; [85.00%]
what the middle-end could do is remove the modulo and instead build an
inner loop (which might then be unrolled as your commented code shows).
More information about the Gcc-bugs
mailing list