Splitting a GPU_Thread loop should probably not make the inner loop GPU_Thread.

[mcourteaux]

When scheduling .gpu_tile(x, y, xo, yo, xi, yi, ...).split(xi, xio, xii, 2) you don't want the inner xii loop to inherit the gpu_threads type. Same for splitting GPU-block loops I think, although that's less common when typing out schedules.

What do you think?

[alexreinking]

I think the idea is that the reconstructed index, xii + 2 * xio, names a GPU_Thread, so what else could it be?

[abadams]

We uniformly preserve loop types when splitting. If you parallelize, vectorize, unroll, etc and then split, both the inner and outer retain the loop type of the parent. GPUThread should be consistent with that.

[mcourteaux]

Let me think about those one by one:

• unroll: splitting an unrolled loop never makes sense if both are unrolled again.
• vectorize: same argument as far as I know; unless it becomes a tensor expression due to some modulo expressions? Kind of an esoteric case?
• parallel: parallelized loop that gets split... I'm in favor of the Alex's argument where the reconstructed loop index names a parallelized loop. When I say parallelize this and split it, I don't want the split inner loop to parallelize intuitively.
• gpu_thread: already discussed: I don't want the inner loop to be a gpu_thread.
• gpu_block: same.
• gpu_lane: I have no idea what this does.
• extern: I have no idea what this does.

Do we have to stick to the way it is today? It just doesn't feel like the right thing. I think we can always construct the inner loop of a split as Serial, and nobody would be surprised. By this point, we're both probably thinking about Hyrum's Law though...