[clang] [llvm] [HLSL][DXIL][SPIRV] Implementation of an abstraction for intrinsic selection of HLSL backends (PR #87171)

[Farzon Lotfi via cfe-commits]

farzonl wrote:

> The `GENERATE_HLSL_INTRINSIC_FUNCTION` abstraction parts of this look fairly reasonable, but do we really want/need dx and spirv intrinsics for the "all" function? This is trivial to generate pretty generic IR for and I don't really see the value of maintaining that the user wrote "all(x)" in source - this doesn't even lower to a DXIL operation in the end. Won't simply expanding this out to checks on each of the elements be likely to give us better optimization opportunities?

So lets look at an example to see why we want an intrinsic:
```hlsl
bool foo(float4 a) {
    return all(a);
}
```

In DXIL  you would be correct it is just a few IR Operations.
```asm
  %5 = fcmp fast une float %1, 0.000000e+00
  %6 = fcmp fast une float %2, 0.000000e+00
  %7 = fcmp fast une float %3, 0.000000e+00
  %8 = fcmp fast une float %4, 0.000000e+00
  %9 = and i1 %5, %6
  %10 = and i1 %9, %7
  %11 = and i1 %10, %8
  %12 = zext i1 %11 to i32
```


But In SPIRV hlsl's all intrinsic maps to an All opcode
```python
%10 = OpConstantComposite %v4float %float_0 %float_0 %float_0 %float_0
%19 = OpFOrdNotEqual %v4bool %18 %10
%20 = OpAll %bool %19
%21 = OpSelect %uint %20 %uint_1 %uint_0
```

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