StableHLO RFC: Support f16- and bf16-based complex types

[Sandra Nerita]

Hi OpenXLA community,

I have opened a StableHLO RFC proposing support for representing and verifying complex values with f16 and bf16 components:

https://github.com/openxla/stablehlo/pull/2993

The proposal expands the supported StableHLO complex component set from {f32, f64} to the explicit closed set {f16, bf16, f32, f64}. It keeps a single complex type domain and applies the new component types wherever an existing StableHLO operation or container already admits complex values.

Although openxla/stablehlo#1794 suggests allowing any floating-point component, the RFC intentionally excludes FP4, FP6, FP8, E8M0, and future formats so that new additions to HLO_Float cannot silently expand the complex type system.

For compatibility, the RFC proposes a new VHLO ComplexV2. Under the proposal, all current StableHLO complex values use V2; f32/f64 can downgrade to historical ComplexV1, while f16/bf16 serialization to an older target fails. The proposal also requires target-aware recursive conversion through containers, signatures, and type-bearing attributes.

This RFC is limited to StableHLO type, specification, verification, and VHLO compatibility behavior. XLA, JAX, legalization, backend kernels, physical ABI, and performance work are explicitly out of scope.

Please leave technical feedback on the RFC PR so that discussion remains centralized there.

Related issue: https://github.com/openxla/stablehlo/issues/1794