tqchen opened a new pull request, #19930:
URL: https://github.com/apache/tvm/pull/19930

   SizeVar tried to encode non-negativity in runtime subtype identity. That 
identity is fragile under ordinary cloning and remapping, so it can disappear 
before the arithmetic consumer that depended on it. Shape, type, and analyzer 
contexts already know where non-negativity is required and can establish the 
fact explicitly at the point of use.
   
   This change removes the SizeVar runtime subtype and collapses construction, 
dispatch, printing, reflection, and analysis onto ordinary Var. It also removes 
the Python, TE, TVMScript, FFI, visitor, and serialization compatibility 
surfaces, while migrating in-tree producers and expectations to the single 
variable model.
   
   This is intentionally a breaking migration: use `tirx.Var` or `te.var` 
instead of `tirx.SizeVar` or `te.size_var`, remove `is_size_var` from 
TVMScript, route custom visitor behavior through the Var callback, and 
regenerate serialized graphs containing the retired type. Code that needs a 
non-negative proof must provide it through the relevant shape/type context or 
an explicit analyzer constraint.
   
   The combined change passes a clean C++ build and repository lint; complete 
TIRX transform coverage passes, and the complete Relax suite matches the 
pre-change baseline exactly, including the replacement node's independently 
reproduced CUDA 13.1/NVRTC environment failures.
   
   Review follow-up: Function-scope unwinding now uses nested `finally` cleanup 
so exceptions from block or scope finalization cannot leave active flags, the 
function stack, or the global builder stack stale. Focused failure injection 
covers both finalizers and verifies that the same builder remains reusable.
   
   GPU documentation follow-up: `VMShapeLowerMutator::Rewrite` opened an outer 
BlockBuilder scope for each Relax function but did not close it. After 
contextual constraints were introduced, multi-function modules retained active 
constraint groups and aborted during teardown. The scope now closes in exact 
LIFO order immediately after normalization, with RAII fallback for exceptional 
exits. A two-symbolic-function regression reproduces the former exit-134 case.
   
   Validation for this repair: a clean uncontended C++ rebuild; one- and 
two-function discriminators; the full VMShapeLower test file (12 passed, 1 
expected xfail); BlockBuilder/type-analysis tests (545 passed); and direct 
`optimize_llm.py` end-to-end with nvcc. The default NVRTC path also gets past 
VMShapeLower and fails only at the independently known local CUDA 13.1 header 
incompatibility. Changed-range pre-commit and whitespace checks pass.
   
   Final exception-path follow-up: a local Relax function rejected before 
`LambdaLift` exposed that base `ExprMutator` scope and block owners skipped 
cleanup when traversal threw. The VMShapeLower guard still closes only its own 
scope; the two scope helpers and three block-owning paths now unwind their own 
frames in exact LIFO order with mechanical nested cleanup and no new API or 
dispatch layer. A subprocess regression exercises ordinary binding, conditional 
inner-scope, dataflow, and SeqExpr-body errors; each returns the expected 
local-function error with no remaining-block warning or process abort.
   
   Final validation: clean uncontended 605-step C++ rebuild and stable no-op 
rebuild; SizeVar-head C++ suite 122/122; focused VMShapeLower, BlockBuilder, 
type-analysis, Relax ExprMutator, and TIRX functor coverage 623 passed with 1 
expected xfail; direct `optimize_llm.py` with nvcc exits zero; full 
changed-range pre-commit passes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to