https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #7 from bin cheng <amker at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> So I think the issue is not dependence testing but loop distribution
> accepting a
> zero dependence distance as OK. Of course dependence analysis is quite
> useless
> here since the accesses are to the same location in every iteration.
>
> Bin, maybe you can share your thoughts on this issue?
>
> The testcase doesn't need bitfields - those just disable the cost model
> which otherwise prevents the distribution.
>
> diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
> index 44423215332..ac272d63c3d 100644
> --- a/gcc/tree-loop-distribution.c
> +++ b/gcc/tree-loop-distribution.c
> @@ -2852,6 +2852,7 @@ loop_distribution::finalize_partitions (class loop
> *loop,
> /* Don't distribute current loop into too many loops given we don't have
> memory stream cost model. Be even more conservative in case of loop
> nest distribution. */
> +#if 0
> if ((same_type_p && num_builtin == 0
> && (loop->inner == NULL || num_normal != 2 || num_partial_memset !=
> 1))
> || (loop->inner != NULL
> @@ -2867,6 +2868,7 @@ loop_distribution::finalize_partitions (class loop
> *loop,
> }
> partitions->truncate (1);
> }
> +#endif
>
> /* Fuse memset builtins if possible. */
> if (partitions->length () > 1)
>
>
> makes the testcase miscompiled even with the : 7 and : 2 commented, so plain
>
> struct S {
> signed m;
> signed e;
> };
I think there is something wrong in data dependence analysis, however,
Richard's change just exposed it.
Given below loop and data refs:
for (...) {
array[loop_invariant] = x; // ref1
array[loop_invariant] ^= 1; // ref2
}
There are both output dependence for ref2(iteration i) -> ref1 (iteration i +
1), and for ref1(iteration i) -> ref2(iteration i).
It seems to me now the first one is missing. Will dig deeper.
