================
@@ -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,
----------------
farzonl wrote:
You have valid points about things needing to be better. Keep in mind though
that this pattern has been extended by multiple devs on the team, that have
gone through PR reviews and got stamps of approval as "good" to merge.
My concern isn't what todays definition of good or bad is. In fact I find the
whole discussion about what is good or terrible to be incredibly subjective. My
concern is more with sticking to a pattern for how we will address certain
problems So that its easier to onboard new folks onto HLSL. I'm fine if those
patterns evolve, but they need to evolve consistently. I'm happy to take
suggestions and file tickets for what needs to improve, but I don't think this
is the PR to do it. We will talk more next week and work towards a plan forward
on this PR and improving the pattern.
https://github.com/llvm/llvm-project/pull/127098
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
