[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