<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Sander,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 22, 2018, at 9:46 AM, Sander De Smalen <<a href="mailto:Sander.DeSmalen@arm.com" class="">Sander.DeSmalen@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Vedant,<br class=""><br class="">Thanks for looking into this. I see your point about not having different code-gen when debug-info is enabled, but can you explain what you mean with it altering code-gen when a vreg is instantiated for an operand that has multiple uses (with at least one non-debug), specifically in the context of FastISel?<br class=""></div></div></blockquote><div><br class=""></div><div>That's a great question. I'm not aware of all the subtleties here, but from what I understand even the order in which vregs are assigned may alter register allocation, and hence codegen. Consider the sequence:</div><div><br class=""></div><div> ... = add i32 %X, %W</div><div> ... = add i32 %Y, %Z</div><div> DBG_VAL %X</div><div><br class=""></div><div>Since FastISel runs bottom-up, the vreg (and possibly the physical register) for %X, %Y, etc. may change due to handling the DBG_VAL too eagerly.</div><div><br class=""></div><div>I'm happy to be wrong about this, though, as that would make life much simpler :).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I figured that if we're trying to match a dbg.value instruction, it is because we want to emit a DBG_VALUE (otherwise why would the dbg.value call still be there in the first place?), and so we should expect all operands to be instantiated. But that assumption is probably incorrect?<br class=""></div></div></blockquote><div><br class=""></div><div>No, I think this is all correct, the tricky part just seems to be how to make this happen without accidentally altering register allocation.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Would it be an idea for FastISel to temporarily ignore the dbg.value until its operands have been instantiated by other (non-debug) instructions, before it will (again) try to create the DBG_VALUE?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes! Adrian suggested this to me as well. I have a WIP prototype, which, when combined with the patch from <a href="https://reviews.llvm.org/D43427" class="">https://reviews.llvm.org/D43427</a> improves an end-to-end test I've got.</div><div><br class=""></div><div>Do you mind running your experiments with the patch? I've tested the patch against a stage2 build of clang, but wasn't able to trigger the deferred debug value emission on anything except synthetic test inputs. Here are the patches:</div><div><br class=""></div><div></div></div></div></body></html>