[llvm] [GlobalISel][TableGen] Support for typed G_FCONSTANT Imm in MIR-patttern (PR #219563)

[Vikash Gupta via llvm-commits]

vg0204 wrote:

> The other changes LGTM. The remaining point is to reach consensus on the design of `GIR_AddCFPImm`, especially how it should handle FP types such as `f16` and `bf16`.

As I dug into the type-flow and it's actually target/build-mode dependent, not unambiguous by default.

`GIR_AddCFPImm` calls `getFltSemanticForLLT(Ty)`. Whether `Ty.isAnyScalar()` is `false` (i.e. `Kind::FLOAT` with real `FpSemantics`, via `APFloat::EnumToSemantics(Ty.getFpSemantics())`) depends entirely on `LLT::getUseExtended()`:

- **With `-gisel-extended-llt`** (AMDGPU's combiner tables, and AArch64's instruction-selector table): f16/bf16 stay distinct `Kind::FLOAT` LLTs → correctly disambiguated.
- **Without it (the default)**: `getLLTForType()` collapses both to a plain `LLT::scalar(16)` before the fp-kind switch even runs, so `Ty.isAnyScalar()` is `true` and `getFltSemanticForLLT` falls into the size-only switch, which hardcodes `IEEEhalf` for 16 bits — bf16 would silently decode with the wrong semantics.

So it's correct for those targets today which sets ExtendedLLT when thery really support `bf16` LLTType (like AMDGPU, AArch64), but latent/ambiguous wherever extended LLT isn't threaded through and stays as default.

https://github.com/llvm/llvm-project/pull/219563