fix(vmi): propagate layouts through integer negation

[chenshengxin2026]

Summary

• treat VMINegIOp as a same-layout VMI op during layout propagation
• add regression coverage for the six integer non-mask vneg cases from [Bug] PTODSL-vmi，vneg 整数类型用例触发 VMI layout 不一致错误 #1373, at both the layout-assignment and full-pipeline levels

Root cause

The unified integer vneg lowers to pto.vmi.negi before layout assignment (ptoas_pipeline.cpp runs vmi-lower-unified-to-legacy ahead of vmi-layout-assignment), but VMINegIOp was missing from isSameLayoutOp in VMILayoutPropagation.cpp.

VMILayoutPropagator::propagateThrough is fail-open: when no transfer is registered for an op it returns success() without recording any constraint. Propagation therefore had no edge between negi's source and result, the two ports were assigned incompatible layouts independently, and the VMI verifier rejected the result:

'pto.vmi.negi' op requires all layout-assigned VMI data values to have the same layout

This also explains why the identical vnot code reported in the issue worked: VMINotOp was already in the list.

The constraint added here is exactly as strong as the op's own contract — VMINegIOp::verify() already calls verifyAllSameVRegShapeAndLayout(..., requireSameElement=true) — so it cannot over-constrain. It also restores consistency across the layout passes: VMINegIOp was already registered in VMILayoutAssignment.cpp, VMILayoutRematerialize.cpp and VMILayoutSinkMaterialization.cpp; propagation was the only one missing it.

Tests

test/lit/vmi_new/vmi_ptoas_cli_integer_vneg_layout.pto covers all six failing cases from the issue (i8 vl1/vl64/vl128, i16 vl1/vl64, i32 vl1) with two RUN lines:

1. pto-test-opt stopping after layout assignment — the primary regression. It isolates the layout invariant from every later stage and asserts the concrete, non-contiguous layout on both negi ports (num_groups = 1, slots = 8 for the vl1 cases, contiguous, lane_stride = 2|4 for the rest), plus the full load/negi/store chain for vneg_i8_vl64. Pinning the concrete layout matters: a bare "a vneg survived" check would keep passing if a future change collapsed these cases to plain contiguous, silently retiring the coverage.
2. ptoas --emit-vpto — proves the whole pipeline completes, guarded by --implicit-check-not so the residual-VMI check applies to the entire output rather than only the region after the last match. This run needs provably 32-byte-aligned dynamic offsets, otherwise physical read legalization fails first and masks the layout regression; the first run has no such prerequisite.

Verification:

• both RUN lines fail on a pre-fix compiler and pass with this change; the layout-assignment run surfaces all six failures directly, whereas the end-to-end run aborts on the first one
• test/lit/vmi_new: 553/553 pass
• full test/lit: no related failures (the only red test locally is npu_validation/deepseek_score_inputs.test, which needs numpy, absent from the local environment)
• built locally in Release with PTOAS_ENABLE_WERROR=ON

Note on the current CI status

vmi-source-patch-check and build-and-test are red for reasons unrelated to this change; both reproduce on other open PRs and on plain main:

• vmi-source-patch-check: packaging/ptoas-vmi/pyproject.toml.patch no longer applies to main's pyproject.toml. Verified by applying the patch to main content directly, with no PR involved.
• build-and-test: the "Validate strict CMake 4 configure" step errors on the deprecated FetchContent_Populate call at cmake/fetch_cann_cmake.cmake:67 under CMake 4.1.3. It fails at configure time, before anything is compiled or any test is run.

As a consequence CI has not yet exercised the new lit test; the results above are from local runs against a build carrying this fix.

Follow-up

#1458 tracks the underlying fragility this bug came from: the same-layout op set is hand-maintained in four separate lists, and layout propagation is fail-open for unregistered ops.

Fixes #1373