http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36842
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-07
14:30:11 UTC ---
(In reply to comment #4)
> I think the report asks for performing loop versioning in the frontend [...]
> where of course the tricky part is creating the appropriate condition
> and deciding if it is worthwhile doing the versioning.
(In reply to comment #4)
> if (Rx and Ry may overlap)
That would be something like:
Rx_min = Rx
Rx_max = &Rx[((rx.dim[0].stride >= 0 && rx.dim[0].ubound >= rx.dim[0].lbound
|| rx.dim[0].stride < 0) || rx.dim[0].stride < 0 && rx.dim[0].lbound == 1 ?
(integer(kind=8)) (integer(kind=4)) rx.dim[0].ubound : 0) * stride.1 +
offset.2]
Something similar for Ry - but a bit more complicated as it has two dimensions
- and then:
if (Rx_min <= Ry_max && Rx_max >= Ry_min)
/* They are overlapping. */
For the LHS one already needs to calculate the extend for the memory allocation
- thus, that extend one gets for free. The effort for the RHS depends on the
number of variables which possibly alias with the LHS. The costs would be the
additional extend calculations, the additional code and in particular the
branching.
In terms of the code, it would mean a larger restructuring as currently
gfc_check_dependency only checks for the dependency; for loop versioning one
needs a function which extracts all the possibly aliasing bounds of the RHS
expression.
The more difficult question is: When should it be applied? Not for -Os, but
otherwise?
(Work around: Writing the code such that the compiler actually knows more by
avoiding POINTER, TARGET and by using CONTIGUOUS - which is difficult for
legacy code [including benchmarks].)
