The GitHub Actions job "CI" on tvm-ffi.git/optimize-structural-map-engine has 
failed.
Run started by GitHub user tqchen (triggered by tqchen).

Head commit for run:
e5090e81779aead80a448ff45287a3c24a85bfaa / tqchen <[email protected]>
[REFACTOR][EXTRA] Optimize StructuralMap engine

Hooked StructuralMap was slower than the mutator it replaces. The cause was
structural: the engine moved every result through representations the compiler
could not eliminate, and expressed the walk in a shape that could not inline.

Result representation. Hooks are C-ABI function pointers returning TVMFFIAny, a
16-byte POD that lives in registers. Wrapping a result in Expected<Any> forces
it to memory, because Expected<Any> is not trivially destructible and so is
classified MEMORY. The convention is now uniform, matching what the visit hooks
already did: the ABI boundary is a raw TVMFFIAny, and a hook or callback body
works in Expected<Any> and moves out at that boundary. Descent through an
unmatched node is exactly that boundary, so it stays raw end to end.
TVM_FFI_S_MUTATE_ASSIGN_OR_RETURN still takes a typed Expected<Any> as input,
so callers keep writing mutator->MutateExpected(...), and it introduces no
helper of its own.

Error context. Hooks no longer attach it. The engine names a node where it
dispatches into that node, which gives exactly one frame per node; previously a
hook named its own node and the engine named it again on some paths. Both
MAYBE_EARLY_RETURN macros lose their node argument as a result, and the visit
engine's own walk no longer routes through the hook-facing macro.

Walk structure. The callback chain was continuation-passing, so each link
nested a lambda inside the previous one and the walk-order body sat at the
bottom of that nest. The mutator now owns its callbacks and tests them with a
`(... || ...)` fold, and the matched-node path -- selection, identity remap,
descent and invocation -- is one straight-line function.

Selection strategy. Statically typed callbacks and runtime ffi.Function links
differ only in how a link is chosen, but that difference ran through the middle
of the walk. They are now separate classes, StructuralMapMutatorObj in the
header and StructuralMapDynMutatorObj in the .cc, sharing only the identity
remap in StructuralMapMutatorBaseObj. That removes a hazard rather than
relocating it: the dynamic form recorded its selected Function in mutable state
on one shared instance, where a post-order walk could descend into a matching
child and overwrite the selection its parent was about to use. Selection is now
a local that descent cannot reach.

Removed: TVM_FFI_S_MUTATE_ASSIGN_FROM and SMutateResultUnchanged, whose split
existed only to skip a conversion that was expensive while the checked macro
built its mismatch message eagerly; AssignOrReturnHelper and the conversion
helpers that existed to recover a type the preprocessor had swallowed; and
MutateWithIdentityRemapExpected, which had one caller, two branches dead at it,
and re-derived a check IsRemappableIdentity already owned.

Added: TVM_FFI_UNSAFE_S_MUTATE_ASSIGN_OR_RETURN_SKIP_CHECK, for hooks that have
measured the type check to matter. It is undefined behavior in a release build
on a wrong-typed result, and has zero call sites here.

One deliberate behavior change: when descent hands back a node whose type no
longer matches the link that selected it, the engine reports a TypeError
instead of silently passing the node through. Default mutation is required to
preserve a node's type, so this can only happen when a hook has broken that
invariant. Match-before-descent ordering, identity-remap entry and exit, and
the pre-order in-place rules are unchanged.

Also fixes AnyUnsafe::CheckAnyStrict, which was missing the Any special case
both of its siblings already had.

Claude-Session: https://claude.ai/code/session_018jQX1azGgoDx3zT6BwsGAk

Report URL: https://github.com/apache/tvm-ffi/actions/runs/33920343387

With regards,
GitHub Actions via GitBox


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

Reply via email to