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