[Bug] MetaSchedule tuning exits successfully with zero candidates measured on Windows
- Dominant language
- Python
- Stars
- 13.7k
- Forks
- 4k
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 112
Description
Could you check whether this is expected on Windows? I ran into this while building a small no-Python TVM integration for Pascal and C#.
### Expected behavior
Candidates are measured, or tuning fails with the underlying runner error instead of exiting successfully.
### Actual behavior
With the stock Windows wheel, MetaSchedule tuning finishes with exit code 0 even though the runner fails on every candidate. The summary shows `Total trials: 0` (`0/217` candidates measured), so no candidates are successfully measured.
The failure occurs while loading each built candidate. In the minimal reproducer, `LocalRunner` loads the built `.tar` artifact and relinks it with clang; on the tested setup, the default configuration first fails because clang is not found on `PATH`, and once clang is available the link still fails on the default target (`x86_64`) and without the TVM runtime import libraries. The link succeeds with `TVM_WIN_TARGET=x86_64-pc-windows-msvc` and a `TVM_WIN_CC` wrapper that invokes clang and adds the TVM runtime import libraries.
The `0/217` result was from ResNet-50. In a separate two-convolution smoke test of the same workaround, 16/16 candidates were measured. I reproduced the original failure with the same stock wheel on two Windows machines.
I'm not sure whether the intended behavior is for the Windows relink path to provide this configuration, or for tuning to fail when the linker fails.
### Environment
apache-tvm 0.26.0 (py3-none-win_amd64 wheel), Python 3.12.10, Windows 11 x64.
### Steps to reproduce
Minimal reproducer for the runner failure:
reproducer and first error
```python
import tvm
from tvm import te
from tvm.s_tir.meta_schedule.builder import LocalBuilder, BuilderInput
from tvm.s_tir.meta_schedule.runner import LocalRunner, RunnerInput
from tvm.s_tir.meta_schedule.arg_info import TensorInfo
N = 256
A = te.placeholder((N, N), "float32", name="A")
B = te.placeholder((N, N), "float32", name="B")
C = te.compute((N, N), lambda i, j: A[i, j] + B[i, j], name="C")
mod = tvm.IRModule({"main": te.create_prim_func([A, B, C])})
target = tvm.target.Target({"kind": "llvm", "num-cores": 8})
(built,) = LocalBuilder().build([BuilderInput(mod, target)])
assert built.error_msg is None, built.error_msg
args = [TensorInfo("float32", (N, N)) for _ in range(3)]
(future,) = LocalRunner().run([RunnerInput(str(built.artifact_path), "cpu", args)])
result = future.result()
print("run_secs :", result.run_secs) # None on Windows
print("error_msg:", result.error_msg) # the linker error below
```
First error on the stock Windows wheel:
```
FileNotFoundError: [WinError 2] # subprocess.Popen(["clang", ...])
RuntimeError: Can not find the LLVM clang for Windows clang.exe. Make sure it's installed and the installation directory is in the %PATH% environment variable.
```
### Triage
* needs-triage
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the supplied LocalBuilder and LocalRunner reproducer on the stock Windows wheel, then inspect the Windows relink path and how tuning handles RunnerInput failures. Verify the clang/PATH and target/import-library configurations described in the issue. Done means linker failures are surfaced instead of a successful zero-candidate result, or the Windows relink path supplies the required configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100