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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
