[clang] [CIR] Upstream initial support for unary op (PR #131369)

Andy Kaylor via cfe-commits cfe-commits at lists.llvm.org
Fri Mar 14 13:33:59 PDT 2025


================
@@ -165,6 +165,54 @@ LValue CIRGenFunction::emitDeclRefLValue(const DeclRefExpr *e) {
   return LValue();
 }
 
+LValue CIRGenFunction::emitUnaryOpLValue(const UnaryOperator *e) {
+  UnaryOperatorKind op = e->getOpcode();
+
+  // __extension__ doesn't affect lvalue-ness.
+  if (op == UO_Extension)
+    return emitLValue(e->getSubExpr());
+
+  switch (op) {
+  case UO_Deref: {
+    cgm.errorNYI(e->getSourceRange(), "UnaryOp dereference");
+    return LValue();
+  }
+  case UO_Real:
+  case UO_Imag: {
+    cgm.errorNYI(e->getSourceRange(), "UnaryOp real/imag");
----------------
andykaylor wrote:

I'm not sure I've been completely consistent about this, but I've been trying to use `MissingFeatures` where something else needs to be done, but the code can reasonably continue without it (such as adding attributes to an op or emitting code to handle sanitizers) and using `errorNYI` where we can't do anything that will produce an even partially correct result. I think this is a case of the latter.

So, for example, in the `matchAndRewrite` handler this PR adds in the lowering code, I used `MissingFeature::vectorType` because we can't possibly get there with a vector type (because it hasn't been added yet), but when it is implemented, we'll need to add handling for it there, but I used `errorNYI` for vector types in `emitScalarPrePostIncDec` because we can get there with a `QualType` that is a vector type, and we don't have any way yet of generating reasonable CIR for that.

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


More information about the cfe-commits mailing list