https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so we simply do not compute self or RR dependences which I think is OK - we
verify the block is dependence free (that's overly restrictive). But that
also means there's no point to even try multiple "same" combinations, short
of trying N*N combinations for N same stores on each side.
Dependence analysis behaves weird for f1() where when removing the b++
stmt we get
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: array1[b_3] = c_6(D);
# ref: array1[b_3];
# base_object: array1[b_3];
#)
#(Data Ref:
# bb: 3
# stmt: array1[b_3] = c_6(D);
# ref: array1[b_3];
# base_object: array1[b_3];
#)
(don't know)
while with the increment in place we have
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: array1[b_4] = c_7(D);
# ref: array1[b_4];
# base_object: array1[b_4];
#)
#(Data Ref:
# bb: 3
# stmt: array1[b_4] = c_7(D);
# ref: array1[b_4];
# base_object: array1[b_4];
#)
(no dependence)
ah, which is because the increment is done in 'int', thus no overflow,
plus we know b is [0, ...], so b is then always out of bounds. Meaning
the alias-oracle computes a max size for the access of zero.
