Induction variables ordering

[mscuttari]

The MCIM data structure is able to handle generic access functions, but it has been designed - and is efficient for - roto-translation accesses (i.e., in the [i +- constant] form) having an identity-like structure (i.e., with the induction variables being accessed in the same order of their declaration).
For this reason, code like the following would lead to inefficiencies because of the identified (d0,d1) -> (d1,d0) affine accesses, in which the induction variables d0 and d1 are ordered differently within the access.

for i in 1:10 loop
  for j in 1:20 loop
    x[j,i] = y[j,i];
  end for;
end for;

However, such code is equivalent to the following, in which only the declaration of the induction variables has been flipped.

for j in 1:20 loop
  for i in 1:10 loop
    x[j,i] = y[j,i];
  end for;
end for;

Here, the affine accesses have become (d0,d1) -> (d0,d1) without any change in the semantics of the model.
A transformation pass should be created to detect such optimization opportunity and reorder the induction variables accordingly. Such pass should iterate on each equation template and analyze all the accesses within, understanding if the amount of accesses that would benefit from this optimization is higher than the amount of accesses that would become non optimizable. Of course, the iteration ranges of equation instances should also be modified accordingly.

[mscuttari]

a4fc44d solves the problem by replacing the Delta data structure with the already existing local matching generator for access functions and by addressing the individual point modifications in a separate IndexSet. The access function groups generator is already capable of handling out-of-order (and also unused) induction variables, making this optimization unneeded.