================
@@ -280,6 +280,22 @@ constexpr bool4 isinf(double4 V) { return
isinf((float4)V); }
_DXC_COMPAT_TERNARY_DOUBLE_OVERLOADS(lerp)
_DXC_COMPAT_TERNARY_INTEGER_OVERLOADS(lerp)
+//===----------------------------------------------------------------------===//
+// lit builtins overloads
+//===----------------------------------------------------------------------===//
+
+template <typename T>
+constexpr __detail::enable_if_t<__detail::is_arithmetic<T>::Value &&
+ (__detail::is_same<double, T>::value ||
----------------
farzonl wrote:
@Icohedron `lit(bool,bool)` case won't be ambiguous if we used functions
instead of templates so there is no emulating the behavior of DXC with what
@kmpeng is doing here. It is emulating clang's function overload behavior.
Second for the most part when we do intrinsics in the frontend and don't have
to write special sema checks for builtins we are guaranteeing more consistent
overload behavior so I don't beleive we are in a scenario where `lit`'s
behavior is going to be inconsistent with other hlsl functions that you can
compile with clang.
Third many of these breaking changes with DXC are intended for HLSL202y. Thats
why `hlsl_compat_overloads.h` came to exist in the first place and why we gate
that file with `#if __HLSL_VERSION <= __HLSL_202x`. We need some level of
compatibility with DXC even if long term we plan to transition away from it.
The ambigious cases I would expect are:
1. mixing of half/float so you don't know which overload to use: `lit(half,
float, float)`, `lit(float, half, half)`, etc.
2. To a significantly lesser extent maybe mixing of other types aswell. DXC
just casts all other types to float so it doesn't have this problem:
https://hlsl.godbolt.org/z/P3qWKhK4K. But maybe `int16_t` type should be cast
to half a float type of the same bitness. Then if the second argument is an
`int32_t` then we would be in the same mixing of half/float case.
https://github.com/llvm/llvm-project/pull/134171
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
