[PATCH] D105207: [debuginfo][lsr] SCEV-based salvaging for LoopStrengthReduction

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added inline comments.


================
Comment at: llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp:6024
+    // Emit a simpler form if only a single location is referenced.
+    if (Values.size() == 1 && Expr[0] == llvm::dwarf::DW_OP_LLVM_arg &&
+        Expr[1] == 0) {
----------------
StephenTozer wrote:
> bjope wrote:
> > jmorse wrote:
> > > bjope wrote:
> > > > Is this some kind of optimization on IR/MIR level?
> > > > 
> > > > Seems like this can result in DBG_VALUE with DW_OP_LLVM_arg in the DIExpression (i.e. neither having a DIArgList or using DBG_VALUE_LIST). But it also seem like that particular scenario doesn't seem to be handled by DwarfDebug. See https://github.com/llvm/llvm-project/issues/55097
> > > > 
> > > > Maybe such things should be expected by all passes? Or is this just a pseudo optimization introducing a special case that complicate logic in other passes?
> > > > 
> > > > Well, I haven't analysed things so closely so maybe this choice is needed for some other reason.
> > > (Drive-by comment) IIRC this clause is here to optimise scenarios where the expression starts with `DW_OP_LLVM_arg, 0`, and where there are no other arguments to the expression, meaning it could be replaced by a plain dbg.value(%123, ..., !DIExpression(blah)), rather than a variadic dbg.value. (Maybe it's faulty, I haven't dug in either).
> > Ok, I see now that the comment for setShortFinalExpression actually say "omit DW_OP_llvm_arg" and not "emit DW_OP_llvm_arg" as I read it the first time.
> > 
> > So maybe the case here is that there are several references to "DW_OP_LLVM_arg, 0" and not only at the expression start. And then we can't just skip adding a DIArgList.
> I think I see the issue here, I brought up the same thing on the more recent LSR-salvage patch: This check is overly permissive. Specifically, the check `Values.size() == 1` only checks that there is only one value in the value list, //not// that there is only one DW_OP_LLVM_arg in the expression; i.e. if the DIExpression is `!(DW_OP_LLVM_arg 0, DW_OP_LLVM_arg 0, DW_OP_plus)`, it would still return true. Thus, when this function sees an expression like that, it assumes that it is safe to emit the short form and drops the first operator, producing `dbg.value(%value, !123, !DIExpression(DW_OP_LLVM_arg 0, DW_OP_plus)`.
> 
> Also, Chris's new patch stack will fix this when it lands, and I'm just about to approve it - will that be suitable, or is a temp fix needed? (For a very quick and dirty temp fix, adding `&& std::count_if(expr_op_iterator(Expr.begin()), expr_op_iterator(Expr.end()), [](auto ExprOp) { return ExprOp.getOp() == llvm::dwarf::DW_OP_LLVM_arg; }) == 1` would be the simplest fix.
Thank you for quick answers and explanations!

>From my point of view I'm happy to use the workaround downstream until the other patches has landed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105207/new/

https://reviews.llvm.org/D105207