I noticed that AutoTVM fallback with reference log doesn’t handle the case that tiliing factors contain -1. AutoTVM SplitEntity supports at most one -1 to be “the rest factor”. For example, split entity [-1, 3, 1, 1] can be applied to the shape of 18. In this case, it is equivalent to [6, 3, 1, 1]. This feature works well and provides the opportunity to share configs amount different shapes.
On the other hand, when users don’t tune the tasks and TVM fallabcks with the reference log on the Tophub, the function fallback_with_reference_log uses match_score to determine which config should used. Specifically, it compares the factors of the current shape with the factors in the log. For example, if we want to fallback a shape 18, then the factors are [1, 2, 3, 6, 9, 18]. Then if one record in the Tophub log has tile size [6, 3, 1, 1], then its product is also 18. It means the match score of this knob is 6/6=1.0 The implementation is at python/tvm/autotvm/task/space.py:1028.
Combining two logics above, when the tile size in Tophub contains -1 (e.g., [-1, 3, 1, 1]), then the product is -3 instead of 18 and it results in the incorrect match score. However, we don’t have other ways to get the actual product of this tile size, because we don’t know the relationship between tile size and the workload shape at this moment.
The most intuitive solution is preventing -1 from appearing to the Tophub log, which is actually true in the past, but no longer a case with CUDA 0.0.7 that has one recod with -1.
Please share your opinion about this issue. Thanks!