Support heterogeneous vector-vector numeric unification

[xmnlab]

Summary

PR #237 centralized numeric unification in BinaryOp by introducing
_unify_numeric_operands, but the remaining parts of the original scope from
#135 still need to be completed. In particular, #135 explicitly called for
centralized numeric unification and promotions across scalars and vectors, and
to use that logic in binops, compares, and FMA. PR #237 wired the new helper
into BinaryOp and described the change as being applied there. :contentReference[oaicite:0]{index=0}

Missing pieces

1. Support heterogeneous vector-vector numeric unification

   • keep rejecting lane-count mismatches
   • when both operands are vectors with the same lane count but different
     element types, promote both to a common element type instead of erroring
   • preserve signed/unsigned integer semantics during widening and int->float
     conversion

2. Reuse the same centralized unification in compare lowering

   • scalar-scalar
   • scalar-vector
   • vector-vector

3. Reuse the same centralized unification in FMA lowering

   • unify all three operands before emission
   • ensure scalar/vector and vector/vector cases behave consistently with
     BinaryOp

Expected behavior

The numeric coercion rules should live in one place and be reused consistently
across arithmetic, compares, and FMA. The result should match the intent of
#135: one unified promotion path for scalar and vector numeric operands,
including signedness handling, FP rank selection, and scalar↔vector splatting. :contentReference[oaicite:1]{index=1}

Suggested tests

Add coverage for at least the following:

• vector<i16> with vector<i32>
• vector<float> with vector<double>
• unsigned vector integer widening
• unsigned vector int->float promotion
• compare operations using mixed scalar/scalar, scalar/vector, and
  vector/vector numeric types
• FMA with mixed scalar/scalar, scalar/vector, and vector/vector numeric types

Notes

PR #237 mentioned the possibility of bringing FMA into the same unification
path later, so this issue tracks that remaining work explicitly. :contentReference[oaicite:2]{index=2}

[Jaskirat-s7]

Hi @xmnlab,

I analyzed the issue and this is what I understood:

PR #237 introduced _unify_numeric_operands to centralize numeric promotion in BinaryOp, but it only completed the scalar ↔ scalar and scalar ↔ vector paths.

The vector ↔ vector branch (when element types differ) was left as a hard error:

if lhs.type.element != rhs.type.element:
    raise Exception(
        f"Vector element type mismatch: "
        f"{lhs.type.element} vs {rhs.type.element}"
    )

This means operations like vector + vector raise an error instead of promoting both to the wider element type — which is the behavior originally requested in #135.

---

Additionally, _unify_numeric_operands is only wired into BinaryOp arithmetic, and two other consumers still perform ad-hoc type checking:

1. Compare operators - Operators: <, >, <=, >=, ==, !=
   The vector ops block only handles +, -, *, /and for compare ops on vectors, it raises:

"Vector binop {op} not implemented"

2. FMA (Fused Multiply-Add)-The third operand (fma_rhs) is checked using a strict type != comparison and it is not unified, leading to failure in cases like:

FMA(vec, vec, vec)

[Jaskirat-s7]

Hi @xmnlab,

The fix that I have been thinking of is that i will try to vover all three gaps in src/irx/builders/llvmliteir.py:

1. Vector–vector promotion : i will replace the element-type mismatch error with the same promotion logic used for scalars (int widening via sext/zext, FP rank selection, and signedness-aware int→float casts), applting element-wise through the existing _cast_value_to_type helper.

Apply this element-wise using the existing _cast_value_to_type helper.

2. Vector compares: i will add <, >, <=, >=, ==, != handling to the vector ops block, using fcmp_ordered / icmp_signed / icmp_unsigned on the already-unified vectors.

3. FMA unification:
   i am replacing the hard type-mismatch error by calling _unify_numeric_operandscalls to promote the third operand (fma_rhs) pairwise against the other two operands

i am also planning to add tests covering all the suggested cases (heterogeneous int/float vectors, unsigned semantics, vector compares, and mixed FMA operands).

Opening a PR.