Lunderberg commented on PR #16361: URL: https://github.com/apache/tvm/pull/16361#issuecomment-1888022497
> I think what the check needs to do is to make sure the loops that are mapped to block vars can not have 2 of them bound to the same thread axis. Hmm. So for the cooperative fetching example that @junrushao mentioned earlier ([link](https://github.com/apache/tvm/blob/main/tests/python/meta_schedule/test_meta_schedule_postproc_rewrite_cooperative_fetch.py#L68-L71)), it would be acceptable because the `ax0_ax1_fused_1` binding is used for `A_shared` and `B_shared`, while the `i0_2_i1_2_fused` binding is used for `C` and `C_local`, and no block has both in use at the same time? How would that be checked after `ConvertBlocksToOpaque`? At that point, only the loop bindings remain, but we still have two loop bindings to the same thread index? > If we have 2 separate loops bound to the same thread axis, then effectively the loop iter space of 2d I x J will be only 1dim I, which is wrong. Completely agreed. My concern is that, because schedule primitives may be part of automatic performance tuning, the resulting schedule could produce results that are faster, but incorrect. My goal would be to have a way to throw an error for my invalid test case, without preventing the cooperative fetching case. Whether that would be easier by having a different sequence of primitives to arrive at cooperative fetching, or a new analysis pathway to forbid the `sch.bind` in my test case, I'm not sure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
