Thanks David and Michael for the clarification.
I think I understand the rational behind those checks in delinearization now.
> Some other languages have stronger guarantees about their array dimensions accesses being in range. But this being a flat C array, there is nothing out-of-bounds going on.
Hmm…perhaps some information about these guarantees can come from the IR that the front-ends produce. I’m wondering if the ‘inrange’ keyword (or maybe a new keyword) can be used for this purpose?
> Think of an array A[2][2] and two accesses:
> A[1][0] = value;
> use(A[0][2]);
> The subscript of the second is out-of-range and will be evaluated to
> the same address as A[1][0]. A dependence-analysis that assumes that
> different subscripts means different addresses will not catch the
> dependence between the two statements.
I had a discussion about this syntax with some C standard experts and there seems to be disagreements on whether an out-of-bound access with respect to an individual dimension is defined behaviour or not. I do not mean to start that discussion here, especially because there may be code in the field relying on certain interpretation of the standard, but just want to mention that option-control maybe a good way to deal with complications like this.
The debug option I had in mind would leave the checks in place by default. I do not intend to decrease the test coverage either. Hopefully the option can actually help us increase test coverage for cases that are currently failing to produce accurate dependence vectors due to the validity conditions being unknown at compile-time. I’ll post a patch for review soon.
Bardia Mahjour
Compiler Optimizations
Hydra Squad Lead
IBM Toronto Software Lab
bmahjour@ca.ibm.com (905) 413-2336
David Green —2019/05/22 06:01:31 PM—Hello Yes, I agree that the SCEV cannot be simplified. Is my understanding correct that it is passe