Address a subtle mismatch involving what loop bounds the code thought
were implemented. The issue comes from the fact that a loop bound predicated on a parameter such as [n] -> { [(-1 + n - floor((3n)/4))] : n > 0 } (which may result from slabbing) will be converted by pw_aff_to_expr() to an unconditional expression, even though the original pw aff is conditional. As a result the previous code might not actually ensure that n > 0. (In prior versions the issue was masked by taking the gist against dom_and_slab, which would remove the constraint that n > 0.) The fix is to teach the code about the actual bounds that get implemented.
Loading
Please register or sign in to comment