Tighten split's extent

[yongfeng-nv]

PassDownDomain always sets inner IterVar's extent to the split factor, even if the parent extent is less than the factor (usually happens when the parent has been reduced to a single point). Although predicates are added to guard bounds, unnecessary likely statements are inserted. They are road blocks for tensorization/intrinsic.

Here is an example from the new test:
Before:

// attr [EF] storage_scope = "global"
allocate EF[float32 * 8]
produce E {
  produce EF {
    for (i, 0, 8) {
      EF[i] = (I[i]*2f)
    }
  }
  for (i.inner, 0, 32) {
    if (likely((i.inner < 8))) {
      if (likely((i.inner < 8))) {
        EF[i.inner] = (EF[i.inner]*2f)
      }
    }
  }
}

After:

// attr [EF] storage_scope = "global"
allocate EF[float32 * 8]
produce E {
  produce EF {
    for (i, 0, 8) {
      EF[i] = (I[i]*2f)
    }
  }
  for (i.inner, 0, 8) {
    EF[i.inner] = (EF[i.inner]*2f)
  }
}

Solution:
Tighten iv's extent to min(parent_extent, factor_or_nparts), only if all of the
following three conditions are met:

1. No leaf IterVar is derived from iv binds to any thread. People may use split
   to force an IterVar extent to match the number of allocated threads to fuse stages
   that require different number of threads. We don't want to change these extents.
2. allow_missing is false, i.e. that PassDownDomain is called by the final InferBound,
   rather than by an early compiler phase, such as rfactor(). We don't want to tighten an
   IterVar in an early phase allowing missing IterVars, because it may bind to a thread later.
3. range_parent's extent is not 0. At lest one Topi test has a case where a tensor has one
   zero-sized dimension. Split creates iv with a positive extent to avoid zero-extent
   IterVar. We don't touch it.

An earlier attempt to this issue is in this PR (#4885). This PR also reports it (#4932).

Follow-up to the discussion in #4885:

1. Comparing with Split node min range is not stringent. #4885, this one doesn't have to change existing tests/schedules and keeps allowing the following use case:

for (int i = 0; i < 31; ++i) {
   B[i] = C[i] + 1
}
for (int j = 0; j < 32; ++j) {
   C[i] = A[i] * 2
}

2. The running time for tests/python/unittest/test_schedule_tensor_core.py:test_tensor_core_batch_conv reduces further (Original: 0.060 ms, Split node min range is not stringent. #4885: 0.035 ms, this one: 0.026ms).

[yongfeng-nv]

@merrymercy, I have updated this PR description and refactor the code. All tests are clear. Please review it. Thank you.

[merrymercy]

Use const reference when possible.
The logic looks good to me.
cc @tqchen for double check.

[yongfeng-nv]

Use const reference when possible.
The logic looks good to me.
cc @tqchen for double check.

Thank you for the careful review. I forgot to check references after refactoring.

[yongfeng-nv]

I don't understand the current failure: https://ci.tvm.ai/blue/organizations/jenkins/tvm/detail/PR-4931/7/pipeline. How do I handle it?

[comaniac]

This CI failure has been fixed several hours ago. Rebasing this branch to upstream and the errors should be gone.

[yongfeng-nv]

I need some help to reproduce the failure locally. I tried the CI twice and both ended with the same failure (e.g. https://ci.tvm.ai/blue/organizations/jenkins/tvm/detail/PR-4931/9/pipeline/). But neither I or fellow engineer was able to reproduce the failure on our local machines. Any suggestion?

I don't mind adding a few temporary debugging dumping code to my change and the test, but the test is the very last one in the entire CI and takes 2-3 hours to reach. Is there any way to get me quickly to this test in CI?

@tqchen

[tqchen]

The error appears to be a flaky test error that may not have things to do with the PR, please try to send a dummy commit to retrigger

[yongfeng-nv]

@merrymercy, I have made your recommended changes. Please review it again. Can you share your use case hitting this issue?

@tqchen, the flaky test finally passed. Thank you for the help. Please double check the logic of this PR and share your thoughts.

[tqchen]

This PR is among one of the PRs affected by the github squash commit bug. We take every contribution serious in the TVM community. The community has decided to use revert/redo approach to amend the contributions as per #5015

@yongfeng-nv Please let us know if you would like us to revert the PR and resend the contribution. Thank you. cc @merrymercy

[yongfeng-nv]

This PR is among one of the PRs affected by the github squash commit bug. We take every contribution serious in the TVM community. The community has decided to use revert/redo approach to amend the contributions as per #5015

@yongfeng-nv Please let us know if you would like us to revert the PR and resend the contribution. Thank you. cc @merrymercy

@tqchen Sure. Thanks.

[tqchen]

@merrymercy can you followup by reverting this PR first? Then @yongfeng-nv can send another PR back

[tqchen]

@yongfeng-nv the revert PR has been merged. Please send another PR back :)