isl_schedule_constraints_compute_schedule: optionally avoid loop coalescing

isl_schedule_constraints_compute_schedule: optionally avoid loop coalescing

Both the Pluto-like scheduler and the Feautrier style scheduler are
prone to producing schedules that implement loop coalescing.
For example, for a square instance set of size 100 in both dimensions,
a schedule of the form 100 x + y could be constructed.
For the Pluto-like scheduler, the driving force is the set of
proximity constraints as the coalescing schedule looks like it
brings instances closer to each other.
For the Feautrier style scheduler, the coalescing schedule
is typically capable of carrying more groups of validity constraints.

Coalescing schedules are undesirable because they essentially turn
a two-dimensional or even higher dimensional set into a one-dimensional
sequence.  This causes the scheduler to get confused about how many
schedule rows still need to get computed, resulting in additional schedule
rows that are considered "coincident" because they only execute
a single instance.
Coalescing schedules also have large coefficients which may cause
some computations that are derived from these schedules to run much slower.

For the Pluto-like scheduler, it is already possible for the user
to try and prevent coalescing schedules through the use of
the schedule_max_coefficient option.  However, the user would
need to either adjust the maximal value to the instance sets or
use a generic (and therefore small) value that may prevent useful
skewings.

For the Feautrier-style scheduler, there was no way
of preventing coalescing schedules.  It makes no sense to bound
the coefficients in this case since Feautrier produces a rational
schedule.  In fact, trying to impose such bounds causes problems
as explained in efc1dc5 (Revert "scheduler: also (optionally) bound
coefficients computed by carry_dependences", Thu May 28 10:58:54 2015 +0200).
Imposing a bound on the ratio between a pair of coefficients is also
not trivial since it would break down into a disjunctive constraint
depending on the sign of the coefficient in the denominator.
It would be possible to prevent the use of the Feautrier-style scheduler
completely, at least its use a fallback for the Pluto-like scheduler,
but it seems that the Feautrier-style scheduler is actually a pretty
good fallback for the Pluto-like scheduler.  In particular, replacing
it by a call to the Pluto-like scheduler that has been modified
to produce a single-dimensional band that does not impose the coincidence
constraints (in case the original call failed due to the use of
the schedule_outer_coincidence option), can produce schedules
without any coincident band members on the same inputs where
a call to the Feautrier-style scheduler would ensure that subsequent
bands computed by the Pluto-like scheduler do have coincident members.

This commit tries to (optionally) prevent or recover from coalescing.
In particular, in case of the Pluto-like scheduler, bounds are imposed
on the schedule coefficients that are derived from the instance sets.
Coalescing occurs when the absolute value of the ratio of
two schedule coefficients is (about) equal to or greater than the size
in the direction of the smaller coefficient.
This commit therefore bounds the schedule coefficients to (about) half
the sizes in the other dimensions.

As explained above, it is not possible to impose such bounds
for the Feautrier-style scheduler.  Instead, this commit detects
that a schedule is (or may be) coalescing by comparing the ratios
between schedule coefficients to the instance set sizes.
If so, the smaller coefficient in the ratio is fixed to zero and
the search for a schedule is continued.  This process repeats
until no more coalescing occurs or until no more dependences can
be carried.  In the latter case, the scheduler reverts to the
previously computed solution.

Instead of detecting coalescing schedules, it would in theory
be possible to adjust the schedule constraints in order to prevent
coalescing.  This could be done by looking at all circuits in
the dependence graph of validity constraints and relaxing those
constraints in the self-dependence constraints along those circuits
that could be abused to perform coalescing.  However, experiments
with a preliminary implementation of this idea showed it to be much
slower than the current scheme of adjusting the schedule afterwards.

Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>