This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
- From: "vries at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 15 Jul 2015 06:12:15 +0000
- Subject: [Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
- Auto-submitted: auto-generated
- References: <bug-66873-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> Does the loop ordering matter? Fortran is a column major language,
> so your nested loops are backwards. One would normally write.
>
> do jj = 0, n - 1
> do ii = 0, n - 1
> x(ii, jj) = ii + jj + 3
> end do
> end do
>
> where the first loop index varies most rapidly.
Thanks for letting me know. I'm obviously not fluent in Fortran.
Interchanging ii and jj in the array access of the example, and again disabling
pass_iv_canon, gives:
...
(Data Dep:
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 500}_3, +, 1}_4
#)
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 500}_3, +, 1}_4
#)
access_fn_A: {{0, +, 500}_3, +, 1}_4
access_fn_B: {{0, +, 500}_3, +, 1}_4
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (3 4 )
distance_vector: 0 0
distance_vector: 1 -500
direction_vector: = =
direction_vector: + -
)
FAILED: data dependencies exist across iterations
...
Again, using -floops-parallelize-all allows the outer loop to be paralelized.