================
@@ -1358,6 +1360,33 @@ mlir::Value
CIRGenFunction::emitScalarConversion(mlir::Value src,
.emitScalarConversion(src, srcTy, dstTy, loc);
}
+mlir::Value ScalarExprEmitter::VisitUnaryLNot(const UnaryOperator *e) {
+ // Perform vector logical not on comparison with zero vector.
+ if (e->getType()->isVectorType() &&
+ e->getType()->castAs<VectorType>()->getVectorKind() ==
+ VectorKind::Generic) {
+ assert(!cir::MissingFeatures::vectorType());
+ cgf.cgm.errorNYI(e->getSourceRange(), "vector logical not");
+ return {};
+ }
+
+ // Compare operand to zero.
+ mlir::Value boolVal = cgf.evaluateExprAsBool(e->getSubExpr());
----------------
andykaylor wrote:
When I went to test the change, it became obvious why this is here, and I
remembered that we had this same discussion a couple of weeks ago with the
for-loop upstreaming. We have a boolean expression, but we need to emit a
value. The AST will have an implicit cast to bool here, but
`EvaluateExprAsBool()` does a couple of other things, like setting the current
PGO statement, and doing RAII on FP operations.
I tried replacing this with emitScalarExpr in the classic codegen, and it does
cause problems when the `!` operator is used with floating point values. I'm
not clear why it doesn't handle the implicit cast in such cases, but it doesn't.
https://github.com/llvm/llvm-project/pull/133966
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
