https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
For some reason predictive commoning thinks that the loads of
p_bm->metricEntries_[idx][0] and [1] are invariant in the innermost loop.
Because:
(Data Dep:
#(Data Ref:
# bb: 9
# stmt: _14 = p_bm_10(D)->metricEntries_[idx_40][0];
# ref: p_bm_10(D)->metricEntries_[idx_40][0];
# base_object: *p_bm_10(D);
# Access function 0: 0
# Access function 1: idx_40
# Access function 2: 0
#)
#(Data Ref:
# bb: 9
# stmt: p_bm_10(D)->metricEntries_[idx_40][0] = _24;
# ref: p_bm_10(D)->metricEntries_[idx_40][0];
# base_object: *p_bm_10(D);
# Access function 0: 0
# Access function 1: idx_40
# Access function 2: 0
#)
(no dependence)
)
err...? There is a anti-dependence here.
Oh. Data dependence in dr_may_alias_p happily uses DR_BASE_OBJECT as
input to the alias oracle but in this case DR_BASE_OBJECT is *p_bm_10(D)
which is an object of size 0 ...
<mem_ref 0x7ffff686a280
type <record_type 0x7ffff68691f8 entries_item_t type_0 BLK
size <integer_cst 0x7ffff66c4ca8 constant 0>
I have a patch.
