================
@@ -193,8 +334,23 @@ LValue CIRGenFunction::emitUnaryOpLValue(const
UnaryOperator *e) {
switch (op) {
case UO_Deref: {
- cgm.errorNYI(e->getSourceRange(), "UnaryOp dereference");
- return LValue();
+ QualType t = e->getSubExpr()->getType()->getPointeeType();
+ assert(!t.isNull() && "CodeGenFunction::EmitUnaryOpLValue: Illegal type");
+
+ assert(!cir::MissingFeatures::lvalueBaseInfo());
+ assert(!cir::MissingFeatures::opTBAA());
+ Address addr = emitPointerWithAlignment(e->getSubExpr());
+
+ // Tag 'load' with deref attribute.
+ if (auto loadOp =
+ dyn_cast<cir::LoadOp>(addr.getPointer().getDefiningOp())) {
+ loadOp.setIsDerefAttr(mlir::UnitAttr::get(&getMLIRContext()));
----------------
bcardosolopes wrote:
> I'm not sure exactly what the static analysis does with this information.
We currently use this in the lifetime checker to decide whether the load is
worth looking at:
https://github.com/llvm/clangir/blob/9f2da98faf36a3c88e61ad307d1261caa0c9d768/clang/lib/CIR/Dialect/Transforms/LifetimeCheck.cpp#L1314
Instead of directly tagging the load during CIRGen it's reasonable to argue
that such information could instead be provided by the result on an analysis
(versus encoded directly into the operation). The design choice at the moment
this was created was to not spend extra compile time given the information is
conveniently available. My take is to leave it as is until we have other passes
that might take advantage of that information, where we could revisit it and
work on the guarantees. FWIW, this is the only operation currently in CIR
encoding this type of semantic.
> BTW, I see that we miss applying the deref attribute if there is a cast on
> the pointer being dereferenced. I'll open an issue for that.
Awesome!
https://github.com/llvm/llvm-project/pull/134317
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
