[clang] [HLSL] Implement the 'and' HLSL function (PR #127098)

[Chris B via cfe-commits]

================
@@ -2245,6 +2245,36 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) {
 
     break;
   }
+  case Builtin::BI__builtin_hlsl_and: {
+    if (SemaRef.checkArgCount(TheCall, 2))
+      return true;
+    if (CheckVectorElementCallArgs(&SemaRef, TheCall))
+      return true;
+
+    // CheckVectorElementCallArgs(...) guarantees both args are the same type.
+    assert(TheCall->getArg(0)->getType() == TheCall->getArg(1)->getType() &&
+           "Both args must be of the same type");
+
+    // check that the arguments are bools or, if vectors,
+    // vectors of bools
+    QualType ArgTy = TheCall->getArg(0)->getType();
+    if (const auto *VecTy = ArgTy->getAs<VectorType>()) {
+      ArgTy = VecTy->getElementType();
+    }
+    if (!getASTContext().hasSameUnqualifiedType(ArgTy,
----------------
llvm-beanz wrote:

I think this is our disconnect. You seem to think there is an expected type. >From the source the use case is ambiguous. Consider this case:

```hlsl
export int16_t4 fn(int16_t4 x, int16_t4 y) {
    return __builtin_hlsl_cross(x, y);
}
```

Do I mean to call cross with `float4` or `half4`? Using `float` would preserve the value range, but using `half` would preserve the size of the input type.

There is nothing at the source level written by the author to indicate what the desired intent is. If this were to go through overload resolution it would return an ambiguous overload and note the possible `float` and `half` overloads. Instead in the hand-rolled `builtin` diagnostics we're arbitrarily choosing an "expected" type and not explaining to the user that there were more than one valid options.

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