Add Windows build workflow in the CI.

[sahas3]

1. Adds a workflow to trigger windows build in the CI similar to the existing one for Linux to address the build CI request captured in Add a build/test workflow for Windows #3985
2. Only non-python based LIT unit tests are enabled in the workflow due to failures reported in Python tests are failing in Windows build #4040
3. The CI is only run against torch-nightly since python based tests are disabled. My understanding is that without the python based tests there's no need to run against the stable version too. If that's not the case, will enable stable as well. Tested that both nightly and stable versions work fine: https://github.com/sahas3/torch-mlir/actions/runs/13477124004

[sahas3]

Hi @sjarus and @justin-ngo-arm, I had to modify the TOSA filecheck tests in this PR as looks like the emission order of back to back tosa.const_shape op is not deterministic across platforms. I am not sure if that's expected but since the current plan is to not run the Windows CI in all PRs (due to build taking too long, please see the unresolved discussion) this is something that might slip through.

[sjarus]

Hi @sjarus and @justin-ngo-arm, I had to modify the TOSA filecheck tests in this PR as looks like the emission order of back to back tosa.const_shape op is not deterministic across platforms. I am not sure if that's expected but since the current plan is to not run the Windows CI in all PRs (due to build taking too long, please see the unresolved discussion) this is something that might slip through.

Thanks! @justin-ngo-arm maybe we want to relax the checks to support such non determinism here ? Since we already have more robust functional testing , ordering restrictions in LIT tests are probably unnecessary.

[justin-ngo-arm]

Hi @sjarus and @justin-ngo-arm, I had to modify the TOSA filecheck tests in this PR as looks like the emission order of back to back tosa.const_shape op is not deterministic across platforms. I am not sure if that's expected but since the current plan is to not run the Windows CI in all PRs (due to build taking too long, please see the unresolved discussion) this is something that might slip through.

Thanks! @justin-ngo-arm maybe we want to relax the checks to support such non determinism here ? Since we already have more robust functional testing , ordering restrictions in LIT tests are probably unnecessary.

Sounds good to me. I can use CHECK-DAG for tosa.const_shape in the future.

[aartbik]

LG on sparse

[sjarus]

Oking the TOSA LIT changes.

[ScottTodd]

Build times so far are really good. Consistently getting high cache hit rates.

https://github.com/llvm/torch-mlir/actions/workflows/ci_windows.yml

Cold cache: 2 hours
Hot cache: 10 minutes!

This new workflow did miss a downstream Windows issue though: #4085. I'll see if I can find what is different about the build (e.g. compiler flags tested, compiler version in the workflow, differences between upstream and downstream build environment).