VMI cmpi "lt" (bare) silently lowers to signed vcmp "lt" — should be rejected or documented as signed-only

[peanutchan]

Summary

VMI pto.vmi.cmpi with bare predicate "lt" (which means unsigned less-than in standard MLIR arith.cmpi convention) silently lowers to pto.vcmp "lt", which performs signed comparison on A5 hardware for i32 operands. Meanwhile, the explicit unsigned form cmpi "ult" is correctly rejected as unsupported.

This means cmpi "lt" produces silently incorrect results when operands can be negative — the user expects unsigned semantics but gets signed.

Reproduction

Test case 1: cmpi "lt" (bare — unsigned in MLIR convention)

// test_cmp_lt_select.pto
%indices = pto.vmi.iota %c0_i32 : i32 -> !pto.vmi.vreg<64xi32>
%num_exp = pto.vmi.broadcast %c64_i32 : i32 -> !pto.vmi.vreg<64xi32>
%in_bounds = pto.vmi.cmpi "lt", %indices, %num_exp
    : !pto.vmi.vreg<64xi32>, !pto.vmi.vreg<64xi32> -> !pto.vmi.mask<64xpred>
%result = pto.vmi.select %in_bounds, %values, %neg_inf
    : !pto.vmi.mask<64xpred>, !pto.vmi.vreg<64xf32>, !pto.vmi.vreg<64xf32>
    -> !pto.vmi.vreg<64xf32>

Lowered output:

%7 = pto.vcmp %3, %5, %4, "lt" : !pto.vreg<64xi32>, !pto.vreg<64xi32>, !pto.mask<b32> -> !pto.mask<b32>
%8 = pto.vsel %result, %6, %7 : !pto.vreg<64xf32>, !pto.vreg<64xf32>, !pto.mask<b32> -> !pto.vreg<64xf32>

Test case 2: cmpi "slt" (signed — correct)

Same lowering:

%7 = pto.vcmp %3, %5, %4, "lt" : !pto.vreg<64xi32>, ...

Test case 3: cmpi "ult" (explicit unsigned — correctly rejected)

error: VMI-UNSUPPORTED: compare predicate ult cannot be lowered to pto.vcmp;
       supported predicates are eq/ne/lt/le/gt/ge, ordered FP forms
       oeq/one/olt/ole/ogt/oge, and signed integer forms slt/sle/sgt/sge

Root Cause

In lib/PTO/Transforms/VMIToVPTO.cpp, getVPTOCmpMode():

if (predicate == "eq" || predicate == "ne" || predicate == "lt" ||
    predicate == "le" || predicate == "gt" || predicate == "ge")
  return predicate;  // ← bare "lt" accepted as-is
// ...
if (predicate == "slt")
  return StringRef("lt");  // ← signed "slt" also maps to "lt"

Both bare "lt" and signed "slt" map to the same vcmp "lt", which is signed on A5 hardware for i32.

In standard MLIR arith.cmpi:

• "lt" = unsigned less-than
• "slt" = signed less-than
• "ult" = explicit unsigned less-than

So bare "lt" should behave like "ult" (unsigned), but instead it behaves like "slt" (signed).

Impact

Any VMI kernel using cmpi "lt" with i32 operands that can be negative will get silently wrong results. For example, the topk_gate out-of-bounds masking pattern from topk_gate_asc.py:

scores_vec[i] = S.vsel(scores_vec[i], neg_inf, S.vcmp(index_vec[i], num_exp, mask_32b, lt))

If translated to VMI as cmpi "lt", and indices happen to be negative (e.g., from a bitcast or subtraction), the masking would be incorrect.

Suggested Fix

Option A (preferred): Reject bare "lt"/"le"/"gt"/"ge" for integer cmpi and require explicit "slt"/"sle"/"sgt"/"sge" (or "ult"/"ule"/"ugt"/"uge" if unsigned is ever supported). This matches the existing test vmi_to_vpto_cmpi_unsigned_predicate_unsupported_invalid.pto which already rejects "ult".

Option B: Document bare "lt"/"le"/"gt"/"ge" as signed-only for integers (i.e., treat them as aliases for "slt"/"sle"/"sgt"/"sge"), and add a warning or note that unsigned integer comparison is not supported on A5.

Environment

• PTOAS-vmi branch: feature-vmi @ 555c8887
• PTOAS binary version: 0.47
• Target: A5 (Ascend 950)