Tags: apache/tvm
Tags
tirx: represent buffer parameters with BufferType (#20086) This phases out PrimFunc.buffer_map entirely. Buffer parameters now carry their BufferType annotation directly in PrimFunc.params, with no compatibility constructor or derived PrimFunc buffer map. The migration updates construction and visitor paths across TIRx, TE, S-TIR, Relax, printers/parsers, packed-ABI lowering, specialization, storage rewriting, and related tests and documentation. BufferType signature shapes use left-to-right match-scope binding: the first quoted shape expression defines missing symbolic variables, and later dimensions, parameters, and matching scalar declarations reuse those exact variables.
[Fix][TIRx] Fix MSVC build of IndexDataTypeNormalizer (#20096) The Windows wheel build for `v0.26.0.rc0` fails to compile: ``` src\tirx\ir\data_type_rewriter.cc(696,47): error C2352: 'tvm::tirx::ExprMutator::VisitPrimExpr': a call of a non-static member function requires an object ``` `StmtExprMutator` derives from both `ExprMutator` and `StmtMutator`, and re-exports the name via `using ExprMutator::VisitPrimExpr;`. MSVC resolves the class-qualified `IndexDataTypeNormalizer::VisitPrimExpr` down to `ExprMutator::VisitPrimExpr` and then fails to form the implicit object conversion. GCC and Clang accept the same expression, so only the Windows leg broke — the macOS and both Linux wheels built fine. The fix calls it through `this` instead, matching every other `VisitPrimExpr` call site in this file. `VisitPrimExpr` is a non-virtual inline helper, so the qualification was suppressing nothing and behavior is unchanged. The other class-qualified call sites in the tree name `StmtExprMutator` directly — that is where the using-declaration lives, so they resolve fine and are left alone. The call was introduced in #19931, which changed `IndexDataTypeNormalizer::VisitExpr` to `IndexDataTypeNormalizer::VisitPrimExpr`; the former resolved unambiguously. Targeting the release branch first to unblock the `v0.26.0.rc0` Windows wheel; it will be ported to `main` separately. Failing job: https://github.com/apache/tvm/actions/runs/31033249253/job/92400739674
[Fix][TIRx] Fix MSVC build of IndexDataTypeNormalizer (#20096) The Windows wheel build for `v0.26.0.rc0` fails to compile: ``` src\tirx\ir\data_type_rewriter.cc(696,47): error C2352: 'tvm::tirx::ExprMutator::VisitPrimExpr': a call of a non-static member function requires an object ``` `StmtExprMutator` derives from both `ExprMutator` and `StmtMutator`, and re-exports the name via `using ExprMutator::VisitPrimExpr;`. MSVC resolves the class-qualified `IndexDataTypeNormalizer::VisitPrimExpr` down to `ExprMutator::VisitPrimExpr` and then fails to form the implicit object conversion. GCC and Clang accept the same expression, so only the Windows leg broke — the macOS and both Linux wheels built fine. The fix calls it through `this` instead, matching every other `VisitPrimExpr` call site in this file. `VisitPrimExpr` is a non-virtual inline helper, so the qualification was suppressing nothing and behavior is unchanged. The other class-qualified call sites in the tree name `StmtExprMutator` directly — that is where the using-declaration lives, so they resolve fine and are left alone. The call was introduced in #19931, which changed `IndexDataTypeNormalizer::VisitExpr` to `IndexDataTypeNormalizer::VisitPrimExpr`; the former resolved unambiguously. Targeting the release branch first to unblock the `v0.26.0.rc0` Windows wheel; it will be ported to `main` separately. Failing job: https://github.com/apache/tvm/actions/runs/31033249253/job/92400739674
[CI] Build CUDA sidecar on plain manylinux, install CUDA manually (#1… …9882) #19754 (besides bumping cibuildwheel to 4.1.0) switched the CUDA runtime sidecar build onto the preinstalled quay.io/manylinux_cuda image and dropped the in-script CUDA toolkit install. On that image the built libtvm_runtime_cuda.so silently lost its libcuda.so.1 dependency: the libcuda.so stub is not where CMake's FindCUDA looks, so CUDA_CUDA_LIBRARY resolved empty and ldd no longer lists libcuda, breaking downstream runtime use. This restores only the sidecar pieces -- the plain manylinux_2_28 image and the curl/rpm/dnf CUDA toolkit install. The cibw 4.1.0 bump is kept (confirmed working). The driver stub is back where FindCUDA finds it, so the sidecar links against libcuda.so.1 again, as ldd confirms. This is a hotfix; a follow-up can re-adopt the CUDA image with the stub resolved explicitly plus a post-build linkage check.
[Fix] Revert C++20-only lambda captures for C++17 build Revert four explicit-this lambda captures ([=, this, ...] -> [=, ...]) in run_codegen.cc, inject_software_pipeline.cc, and cudnn_json_runtime.cc. These were introduced by the C++20 baseline upgrade (#19734); after reverting the baseline to C++17, MSVC rejects capturing 'this' explicitly under a '=' capture-default (error C3791) -- that form is C++20-only. GCC and Clang accept it as an extension in C++17, which is why only the Windows wheel build failed. Dropping the explicit 'this' ('=' captures it implicitly in C++17) restores the MSVC build with no behavior change.
[Fix] Revert C++20-only lambda captures for C++17 build Revert four explicit-this lambda captures ([=, this, ...] -> [=, ...]) in run_codegen.cc, inject_software_pipeline.cc, and cudnn_json_runtime.cc. These were introduced by the C++20 baseline upgrade (#19734); after reverting the baseline to C++17, MSVC rejects capturing 'this' explicitly under a '=' capture-default (error C3791) -- that form is C++20-only. GCC and Clang accept it as an extension in C++17, which is why only the Windows wheel build failed. Dropping the explicit 'this' ('=' captures it implicitly in C++17) restores the MSVC build with no behavior change.
[Arith] Make Analyzer a tvm-ffi Object (#19675) This PR makes `arith::Analyzer` a first-class tvm-ffi object. The implementation splits the previous concrete `Analyzer` class into: - `AnalyzerObj`, the mutable object node that owns analyzer state, sub-analyzers, caches, and bindings - `Analyzer`, a reference-counted `ObjectRef` handle that can be passed across the tvm-ffi boundary This allows Python and C++ to share the same analyzer instance, so bindings, constraints, and cached facts can persist across FFI calls. Public APIs that accept an analyzer now use `const arith::Analyzer&`, while internal helper APIs that only borrow the object continue to use `AnalyzerObj*`. --------- Co-authored-by: Ubospica <ubospica@gmail.com>
PreviousNext