Add a variant of the clspv target that is built using spir64.
This is a pre-requisite to supporting spir64 in clspv which is
required to take advantage of SPV_KHR_physical_storage_buffer which
in turn enables more OpenCL C programs to be compiled with clspv.
Which version of physical storage buffer do you intend to support? Because if 64-bit integers can be assumes, then the clspv64 target should use the generic implementation of fma instead of the one the standard clspv target uses to avoid all the carry bit logic.
I've done my prototyping assuming support for 64-bit integers but, unfortunately, some targets of interest don't support 64-bit yet so I will likely end up implementing support for both paths (64-bit integers and uvec2) in clspv. I've mapped the clspv64 target to the version that doesn't require 64-bit integers for compatibility, to avoid carrying two builds of the library in clspv (each build adds about 2MB to the binary size). Looking at both implementations of fma, I'm not overly concerned about always using the version that doesn't require support for 64-bit integers for now. Both will be excruciatingly slow compared to hardware support anyway. Longer-term we can either assume support for 64-bit integers once more prevalent in the Vulkan ecosystem or introduce an additional variant of the library but I'd rather treat this as a future optimisation if that works for you.
Was this tested on an existing device, or is it just for completion (since there already is clspv target)?
wrong formatting. If you spill over to the next line keep NOT close to the negated element and align to match the first line
just add another elseif branch for better readability. Nested if is not saving much