After this PR merged, workload was changed as length of padding attribute in conv2d changes from two to four in asymetric padding workloads.
It turns out the Tophub schedules do not match the workloads with padding attribute length 4 (even for symetric padding), so we have to update Tophub to cover length-4-padding workloads. Intuitively, we could just add asymetric padding workloads to Tophub so that we have both length-2-padding and length-4-padding workloads. However, this solution has two issues:
Updating Tophub cannot completely resolve this problem. Since the model from other frontends (e.g., MXNet) still use length-2-padding, we may need to tune the same workload twice (length-4-padding and length-2-padding).
Symetric padding workloads from TF model still have to be re-tuned as padding is fused into conv2d. Previously in TF frontend, padding values is converted to be a padding operator prior to the conv2d operator so the padding of some conv2d ops from TF models are (0, 0). It was now fused into conv2d as other frontends.
In this RFC, we propose several solutions to fully resolve this issue:
Approach 1: Change all frontend to generate lengh-4-padding workloads.
- Pros: easy to modify and straightforward.
- Cons: there’s no strict rule to enforce this policy, so it might be violated again in the future.
Appraoch 2: Propose a new pass or intergete it into an existing pass to tranfrom the padding length of all cov2d workloads to 4.
- Pros: This is a general solution for all frontends and AutoTVM.
- Cons: 1) Add additional overhead and complexity to the pass. 2) It might be a little bit ad-hoc.
Approach 3: When AutoTVM is extracting tasks, it unifies the length of all conv2d padding to 4.
- Pros: We only need to modify AutoTVM task extraction without touching any other parts.
- Cons: This is even more ad-hoc.
Any comments and thoughts are welcome:)