[val] Do not reject OpExtInst for BFloat16/FP8 result types

[aobolensk]

Needed for llvm/llvm-project#202859

[aobolensk]

@MrSidims could you please take a look?

[MrSidims]

I'm unsure if we have instruction sets that supports FP8.

Regarding bfloat - this requires a bit of research, the only extension that allows usage of such values is (from the best of my knowledge) SPV_INTEL_bfloat16_arithmetic (allows for OpenCL ExtInst), but when accounting for it - the change must be guarded by checking if the extension is enabled. At the same time the extension doesn't present in the Registry and it's not really a common practice to introduce it to SPIR-V Tools.

[aobolensk]

I'm unsure if we have instruction sets that supports FP8.

Regarding bfloat - this requires a bit of research, the only extension that allows usage of such values is (from the best of my knowledge) SPV_INTEL_bfloat16_arithmetic (allows for OpenCL ExtInst), but when accounting for it - the change must be guarded by checking if the extension is enabled. At the same time the extension doesn't present in the Registry and it's not really a common practice to introduce it to SPIR-V Tools.

It seems to be already checked as a part of extensions verifications. I have added more tests for these cases to protect (rather, to prove that this protection already exists) from using bf16/fp8 in OpExtInst instruction without corresponding caps

[alan-baker]

It feels like this must be supported to get debug info support.

[alan-baker]

Also, extension instructions are in the allowlist for bfloat16 and fp8.

[MrSidims]

It feels like this must be supported to get debug info support.

Ahhh, I get it. No objections from me then.

[aobolensk]

CI failures seem to be unrelated with my changes

[alan-baker]

Can you trying rebasing, another PR attempted to fix that.

[aobolensk]

Could you please restart Build and Test with Bazel / build (windows-2025) (pull_request) job? @alan-baker