Guard should not be added to loop.

[wlaw59]

SimplifyHull is run on Level 0 and it is discovered that the last constraint doesn’t belong. The CG_Loop object is created to have an iteration space (bounds) of 0 <= t1 < N and the Gist operation is used to separate the last constraint and save it as a guard. However, and this is what was missing from the code, if the max arity of the UFs in the guard is greater than or equal to the loop level, the guard should not be added to that loop. When it is added to the loop it is also added to the currently known constraints. To fix this I simply checked for legality and failed to add the guard to the loop in the case that it wouldn’t be legal.

// if this guard contains an UF and that UF takes the iterator of
// this level as an argument we should postpone creating the guard
// we can tell this by finding the arity of the UF, if there is one
// and looking at our depth
int ufs_arity = guard_.max_ufs_arity();
std::cerr << "guard contains ufs arity: " << ufs_arity << " we are at level " << level_ << std::endl;
if(ufs_arity >= level_){
  guard_ = Relation::True(num_level()); // this is a replacement
}

code_gen/src/CG.cc: 631

When the above code is included the output is the following:

for(t1 = 0; t1 <= N-1; t1++) {
  for(t2 = 0; t2 <= F(t1)-1; t2++) {
    s0(t1,t2);
  }
}

When that statement is excluded we get the following illegal code:

if (F(t1) >= 1) {
  for(t1 = 0; t1 <= N-1; t1++) {
    for(t2 = 0; t2 <= F(t1)-1; t2++) {
      s0(t1,t2);
    }
  }
}

This makes sense because the guard (F(t1) >= 1) is being attached to the t1 loop. Now, my first concern was that the guard disappeared completely, and so that might be a problem. Actually, the code generator takes an Intersection of the known and current constraints. The Intersection operation is smart enough to see that the guard constraint is redundant with the upper and lower bounds of the inner loop, so it is legally eliminated.