Request: Support for new VK_KHR_shader_fma extension? (needs a corresponding GLSL GL_KHR_shader_fma?)

Hi,
seems support for it isn't in glslang yet, right?
interested as:
https://docs.vulkan.org/refpages/latest/refpages/source/VK_KHR_shader_fma.html:
"Vulkan currently exposes an fma primitive that can give the reduced cost, but it is not guaranteed to be a fused operation, so the accuracy cannot be relied on"

also from https://registry.khronos.org/OpenGL-Refpages/gl4/html/fma.xhtml
"fma performs, where possible, a fused multiply-add operation, returning a * b + c. In use cases where the return value is eventually consumed by a variable declared as precise.."

so as I see in glsl spec of fma op, "where possible" means "true fma" wasn't guaranteed even using a "precise" return operation..
now SPV_KHR_fma add OpFmaKHR where "true fma: one fused op" is guaranted..
so logical enablement of this in glslang is when using precise on return value of fma op, map that fma to SPIR-V OpFmaKHR, and include OpExtension "SPV_KHR_fma" in generated SPIR-V..

but for that seems a corresponding GLSL extension is missing GL_KHR_shader_fma..
with that using #extension GL_KHR_shader_fma should enabled this new behaviour..
or if not warrants a new GLSL ext, a new argument to glslang to force this new behaviour could be added also, right? (like --use_vk_shader_khr_fma, but seems like a hack)

thanks..

Start by reviewing glslang's existing handling of the GLSL fma operation and precise results, then compare the requested behavior with VK_KHR_shader_fma, SPV_KHR_fma, and the referenced GLSL specification. The scope should be resolved first: determine whether a GLSL extension or a glslang argument is appropriate, then define completion as correct extension recognition and SPIR-V generation with coverage for the new behavior.

Written by the indexing model from the issue text.