<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 28, 2018, at 7:19 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="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Hi Vedant,<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Apologies for the delayed response, we’ve been in the process of moving to a new office over the past week, which caused the necessary distraction.<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">I wonder if the reason for the different register allocation in your example is because the DBG_VAL actually increases the liverange of %X beyond its last real use? Using normal instruction selection, SDDbgValues are first scheduled in ScheduleDAGSDNodes before they are turned into DBG_VALUE instructions, where FastISel creates the machine DBG_VALUE instructions directly from the IR in the order it finds them.</span></div></div></div></blockquote><div><br class=""></div><div>Possibly -- sorry, I did not double-check that your original patch gives a different register allocation for this example, and haven't really dug into it.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Trying out your patches, I found that dbg.values are still dropped when FastISel needs to fall back on normal ISel for a preceding instruction (e.g. a dynamic alloca). This will call ‘flushLocalValueMap()’, and so even when the preceding instruction(s) would cause that operand to be instantiated as a vreg, the dbg.value is already dropped. Can your patch be extended so that the deferred values are also emitted<span class="Apple-converted-space"> </span><i class="">after</i><span class="Apple-converted-space"> </span>falling back on normal ISel?</span></div></div></blockquote><div><br class=""></div><div>That sounds reasonable, but I'm worried that the whole approach is a bit too hacky. I wonder if it'd be simpler to just run FastISel in the forward direction, as Paul & Eric mentioned? Going back to the example below, if %X is assigned a vreg before %Z, istm we wouldn't need to play any tricks to handle the DBG_VAL.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Perhaps if that is not easily possible, I wonder if we can do some pre-scheduling of dbg.values as preparation to codegen (on LLVM IR level) to make sure a dbg.value is never the last use of an instruction.</span></div></div></blockquote><div><br class=""></div><div>I'm brand new to this, but from what I've heard the placement of dbg values relative to other instructions is consequential. Adrian or Eric might be in a better position to comment.</div><div><br class=""></div><div>best,</div><div>vedant</div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""> However, I’m not sure though if this would go against the whole idea of how debug values are handled in LLVM, or even whether the end-result is always correct or the same? (Note that this would not address the test you added in no-materialize-dbg-val-fastisel.ll, where the only use of a variable is the dbg.value itself). Do you have any thoughts on that?<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Thanks,<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class="">Sander<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 12pt;" class="">From:<span class="Apple-converted-space"> </span></span></b><span style="font-size: 12pt;" class=""><<a href="mailto:vsk@apple.com" style="color: purple; text-decoration: underline;" class="">vsk@apple.com</a>> on behalf of Vedant Kumar <<a href="mailto:vsk@apple.com" style="color: purple; text-decoration: underline;" class="">vsk@apple.com</a>><br class=""><b class="">Date:<span class="Apple-converted-space"> </span></b>Thursday, 22 February 2018 at 19:14<br class=""><b class="">To:<span class="Apple-converted-space"> </span></b>Sander De Smalen <<a href="mailto:Sander.DeSmalen@arm.com" style="color: purple; text-decoration: underline;" class="">Sander.DeSmalen@arm.com</a>><br class=""><b class="">Cc:<span class="Apple-converted-space"> </span></b>llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" style="color: purple; text-decoration: underline;" class="">llvm-commits@lists.llvm.org</a>>, Adrian Prantl <<a href="mailto:aprantl@apple.com" style="color: purple; text-decoration: underline;" class="">aprantl@apple.com</a>>, Mikael Holmén <<a href="mailto:mikael.holmen@ericsson.com" style="color: purple; text-decoration: underline;" class="">mikael.holmen@ericsson.com</a>><br class=""><b class="">Subject:<span class="Apple-converted-space"> </span></b>Re: [llvm] r325438 - [DebugInfo][FastISel] Fix dropping dbg.value()<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><a name="_MailOriginalBody" class="">Hi Sander,<span class="Apple-converted-space"> </span><o:p class=""></o:p></a></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">On Feb 22, 2018, at 9:46 AM, Sander De Smalen <</span><a href="mailto:Sander.DeSmalen@arm.com" style="color: purple; text-decoration: underline;" class=""><span class="">Sander.DeSmalen@arm.com</span><span class=""></span></a><span class="">> wrote:<o:p class=""></o:p></span></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span 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?<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">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:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""> ... = add i32 %X, %W<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""> ... = add i32 %Y, %Z<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""> DBG_VAL %X<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">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.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">I'm happy to be wrong about this, though, as that would make life much simpler :).<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span 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?<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">No, I think this is all correct, the tricky part just seems to be how to make this happen without accidentally altering register allocation.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span 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?<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Yes! Adrian suggested this to me as well. I have a WIP prototype, which, when combined with the patch from </span><a href="https://reviews.llvm.org/D43427" style="color: purple; text-decoration: underline;" class=""><span class="">https://reviews.llvm.org/D43427</span><span class=""></span></a><span class=""> improves an end-to-end test I've got.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">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:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">I'm fine reverting the patch for now though.<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Right, I think that would be best for now -- at least to resolve the assertion failure.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">thanks!<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">vedant<o:p class=""></o:p></span></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class="">Sander<br class=""><br class=""><br class="">On 21/02/2018, 23:51, "</span><a href="mailto:vsk@apple.com" style="color: purple; text-decoration: underline;" class=""><span class="">vsk@apple.com</span><span class=""></span></a><span class=""><span class="Apple-converted-space"> </span>on behalf of Vedant Kumar" <</span><a href="mailto:vsk@apple.com" style="color: purple; text-decoration: underline;" class=""><span class="">vsk@apple.com</span><span class=""></span></a><span class="">> wrote:<br class=""><br class=""> I discussed this with Adrian offline, who brought up that the general idea of materializing the debug value if it has > 0 uses can still alter code generation. We'll need some other approach.<br class=""><br class=""> @Sander, should we revert this change until we have a solution?<br class=""><br class=""> vedant<br class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">On Feb 21, 2018, at 2:56 PM, Vedant Kumar <</span><a href="mailto:vsk@apple.com" style="color: purple; text-decoration: underline;" class=""><span class="">vsk@apple.com</span><span class=""></span></a><span class="">> wrote:<br class=""><br class="">Here's a possible fix:<br class=""><br class="">diff --git a/include/llvm/CodeGen/FastISel.h b/include/llvm/CodeGen/FastISel.h<br class="">index 85bb826dcb8..251d76369fc 100644<br class="">--- a/include/llvm/CodeGen/FastISel.h<br class="">+++ b/include/llvm/CodeGen/FastISel.h<br class="">@@ -262,9 +262,10 @@ public:<br class=""> /// to the current block. Return true if selection was successful.<br class=""> bool selectOperator(const User *I, unsigned Opcode);<br class=""><br class="">- /// \brief Create a virtual register and arrange for it to be assigned the<br class="">- /// value for the given LLVM value.<br class="">- unsigned getRegForValue(const Value *V);<br class="">+ /// \brief Create or look up a virtual register and arrange for it to be<br class="">+ /// assigned the value for the given LLVM value. A virtual register may only<br class="">+ /// be created if \p AllowMaterialize is true.<br class="">+ unsigned getRegForValue(const Value *V, bool AllowMaterialize = true);<br class=""><br class=""> /// \brief Look up the value to see if its value is already cached in a<br class=""> /// register. It may be defined by instructions across blocks or defined<br class="">diff --git a/lib/CodeGen/SelectionDAG/FastISel.cpp b/lib/CodeGen/SelectionDAG/FastISel.cpp<br class="">index 686fe88a2be..7270aeb25b2 100644<br class="">--- a/lib/CodeGen/SelectionDAG/FastISel.cpp<br class="">+++ b/lib/CodeGen/SelectionDAG/FastISel.cpp<br class="">@@ -192,7 +192,7 @@ bool FastISel::hasTrivialKill(const Value *V) {<br class=""> cast<Instruction>(*I->user_begin())->getParent() == I->getParent();<br class="">}<br class=""><br class="">-unsigned FastISel::getRegForValue(const Value *V) {<br class="">+unsigned FastISel::getRegForValue(const Value *V, bool AllowMaterialize) {<br class=""> EVT RealVT = TLI.getValueType(DL, V->getType(), /*AllowUnknown=*/true);<br class=""> // Don't handle non-simple values in FastISel.<br class=""> if (!RealVT.isSimple())<br class="">@@ -216,12 +216,18 @@ unsigned FastISel::getRegForValue(const Value *V) {<br class=""> return Reg;<br class=""><br class=""> // In bottom-up mode, just create the virtual register which will be used<br class="">- // to hold the value. It will be materialized later.<br class="">+ // to hold the value. It will be materialized later if it has uses.<br class=""> if (isa<Instruction>(V) &&<br class=""> (!isa<AllocaInst>(V) ||<br class="">- !FuncInfo.StaticAllocaMap.count(cast<AllocaInst>(V))))<br class="">+ !FuncInfo.StaticAllocaMap.count(cast<AllocaInst>(V))) &&<br class="">+ (AllowMaterialize || !V->use_empty()))<br class=""> return FuncInfo.InitializeRegForValue(V);<br class=""><br class="">+ // If we're not allowed to materialize a value (say, because it's a debug<br class="">+ // value), bail out now.<br class="">+ if (!AllowMaterialize)<br class="">+ return 0;<br class="">+<br class=""> SavePoint SaveInsertPt = enterLocalValueArea();<br class=""><br class=""> // Materialize the value in a register. Emit any instructions in the<br class="">@@ -1235,7 +1241,7 @@ bool FastISel::selectIntrinsicCall(const IntrinsicInst *II) {<br class=""> .addImm(0U)<br class=""> .addMetadata(DI->getVariable())<br class=""> .addMetadata(DI->getExpression());<br class="">- } else if (unsigned Reg = getRegForValue(V)) {<br class="">+ } else if (unsigned Reg = getRegForValue(V, /*AllowMaterialize=*/false)) {<br class=""> // FIXME: This does not handle register-indirect values at offset 0.<br class=""> bool IsIndirect = false;<br class=""> BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc, II, IsIndirect, Reg,<br class=""><br class="">vedant<br class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">On Feb 21, 2018, at 2:40 PM, Vedant Kumar via llvm-commits <</span><a href="mailto:llvm-commits@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">llvm-commits@lists.llvm.org</span><span class=""></span></a><span class="">> wrote:<br class=""><br class="">You can reduce this even further by running `opt -strip -metarenamer -debugify` on the file Mikael attached:<br class=""><br class=""><reduced.ll><br class=""><br class="">Stepping back a bit, it looks like calling getRegForValue() here may materialize a Value in a new vreg. Doesn't that alter code generation, and if so, is that actually what we want? (As I understand it it's llvm policy that debug info intrinsics shouldn't affect codegen, but perhaps I'm misreading this and that's not what's happening here.)<br class=""><br class="">vedant<br class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">On Feb 21, 2018, at 3:53 AM, Mikael Holmén via llvm-commits <</span><a href="mailto:llvm-commits@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">llvm-commits@lists.llvm.org</span><span class=""></span></a><span class="">> wrote:<br class=""><br class="">Hi Sander,<br class=""><br class="">I stumbled upon a case that hits an assert with this patch:<br class=""><br class="">llc -O0 -mtriple x86_64-unknown-linux-gnu -mcpu=x86-64 -o - reduced.ll<br class=""><br class="">gives<br class=""><br class="">llc: ../lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:1600: void llvm::SelectionDAGBuilder::CopyToExportRegsIfNeeded(const llvm::Value *): Assertion `!V->use_empty() && "Unused value assigned virtual registers!"' failed.<br class="">#0 0x0000000001e85f04 PrintStackTraceSignalHandler(void*) (build-all/bin/llc+0x1e85f04)<br class="">#1 0x0000000001e86676 SignalHandler(int) (build-all/bin/llc+0x1e86676)<br class="">#2 0x00007f3824026330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)<br class="">#3 0x00007f3822c15c37 gsignal /build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0<br class="">#4 0x00007f3822c19028 abort /build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0<br class="">#5 0x00007f3822c0ebf6 __assert_fail_base /build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0<br class="">#6 0x00007f3822c0eca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)<br class="">#7 0x0000000001cb1492 llvm::SelectionDAGBuilder::CopyToExportRegsIfNeeded(llvm::Value const*) (build-all/bin/llc+0x1cb1492)<br class="">#8 0x0000000001cb06e8 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) (build-all/bin/llc+0x1cb06e8)<br class="">#9 0x0000000001d4ba0e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, true, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, true, false, void>, false, true>, bool&) (build-all/bin/llc+0x1d4ba0e)<br class="">#10 0x0000000001d4a501 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (build-all/bin/llc+0x1d4a501)<br class="">#11 0x0000000001d467e7 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build-all/bin/llc+0x1d467e7)<br class="">#12 0x000000000112c011 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build-all/bin/llc+0x112c011)<br class="">#13 0x00000000015f3659 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (build-all/bin/llc+0x15f3659)<br class="">#14 0x00000000018fa2b8 llvm::FPPassManager::runOnFunction(llvm::Function&) (build-all/bin/llc+0x18fa2b8)<br class="">#15 0x00000000018fa4f8 llvm::FPPassManager::runOnModule(llvm::Module&) (build-all/bin/llc+0x18fa4f8)<br class="">#16 0x00000000018fa9d5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all/bin/llc+0x18fa9d5)<br class="">#17 0x00000000006d9305 compileModule(char**, llvm::LLVMContext&) (build-all/bin/llc+0x6d9305)<br class="">#18 0x00000000006d6a7b main (build-all/bin/llc+0x6d6a7b)<br class="">#19 0x00007f3822c00f45 __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0<br class="">#20 0x00000000006d427d _start (build-all/bin/llc+0x6d427d)<br class="">Stack dump:<br class="">0. Program arguments: build-all/bin/llc -O0 -mtriple x86_64-unknown-linux-gnu -mcpu=x86-64 -o - reduced.ll<br class="">1. Running pass 'Function Pass Manager' on module 'reduced.ll'.<br class="">2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@func_11'<br class=""><br class="">Regards,<br class="">Mikael<br class=""><br class="">On 02/17/2018 05:42 PM, Sander de Smalen via llvm-commits wrote:<br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Author: s.desmalen<br class="">Date: Sat Feb 17 08:42:54 2018<br class="">New Revision: 325438<br class="">URL:<span class="Apple-converted-space"> </span></span><a href="http://llvm.org/viewvc/llvm-project?rev=325438&view=rev" style="color: purple; text-decoration: underline;" class=""><span class="">http://llvm.org/viewvc/llvm-project?rev=325438&view=rev</span><span class=""></span></a><span class=""><br class="">Log:<br class="">[DebugInfo][FastISel] Fix dropping dbg.value()<br class="">Summary:<br class=""></span><a href="https://llvm.org/PR36263" style="color: purple; text-decoration: underline;" class=""><span class="">https://llvm.org/PR36263</span><span class=""></span></a><span class=""><span class="Apple-converted-space"> </span>shows that when compiling at -O0 a dbg.value()<br class="">instruction (that remains from an original dbg.declare()) is dropped<br class="">by FastISel. Since FastISel selects instructions by iterating a basic<br class="">block backwards, it drops the dbg.value if one of its operands is not<br class="">yet instantiated by a previously selected instruction.<br class="">Instead of calling 'lookUpRegForValue()' we can call 'getRegForValue()'<br class="">instead that will insert a placeholder for the operand to be filled in<br class="">when continuing the instruction selection.<br class="">Reviewers: aprantl, dblaikie, probinson<br class="">Reviewed By: aprantl<br class="">Subscribers: llvm-commits, dstenb, JDevlieghere<br class="">Differential Revision:<span class="Apple-converted-space"> </span></span><a href="https://reviews.llvm.org/D43386" style="color: purple; text-decoration: underline;" class=""><span class="">https://reviews.llvm.org/D43386</span><span class=""></span></a><span class=""><br class="">Added:<br class=""> llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll<br class="">Modified:<br class=""> llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp<br class=""> llvm/trunk/test/DebugInfo/X86/fission-ranges.ll<br class="">Modified: llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp<br class="">URL:<span class="Apple-converted-space"> </span></span><a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp?rev=325438&r1=325437&r2=325438&view=diff" style="color: purple; text-decoration: underline;" class=""><span class="">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp?rev=325438&r1=325437&r2=325438&view=diff</span><span class=""></span></a><span class=""><br class="">==============================================================================<br class="">--- llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp (original)<br class="">+++ llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp Sat Feb 17 08:42:54 2018<br class="">@@ -1235,7 +1235,7 @@ bool FastISel::selectIntrinsicCall(const<br class=""> .addImm(0U)<br class=""> .addMetadata(DI->getVariable())<br class=""> .addMetadata(DI->getExpression());<br class="">- } else if (unsigned Reg = lookUpRegForValue(V)) {<br class="">+ } else if (unsigned Reg = getRegForValue(V)) {<br class=""> // FIXME: This does not handle register-indirect values at offset 0.<br class=""> bool IsIndirect = false;<br class=""> BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc, II, IsIndirect, Reg,<br class="">Added: llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll<br class="">URL:<span class="Apple-converted-space"> </span></span><a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll?rev=325438&view=auto" style="color: purple; text-decoration: underline;" class=""><span class="">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll?rev=325438&view=auto</span><span class=""></span></a><span class=""><br class="">==============================================================================<br class="">--- llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll (added)<br class="">+++ llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll Sat Feb 17 08:42:54 2018<br class="">@@ -0,0 +1,54 @@<br class="">+; RUN: llc -O0 -stop-after=livedebugvalues -fast-isel=true < %s | FileCheck %s<br class="">+<br class="">+; CHECK: ![[LOCAL:[0-9]+]] = !DILocalVariable(name: "__vla_expr",<br class="">+; CHECK: DBG_VALUE {{.*}} ![[LOCAL]]<br class="">+<br class="">+; ModuleID = '<stdin>'<br class="">+source_filename = "foo.c"<br class="">+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"<br class="">+target triple = "x86_64-unknown-linux-gnu"<br class="">+<br class="">+; Function Attrs: noinline nounwind optnone uwtable<br class="">+define void @foo(i32 %n) local_unnamed_addr #0 !dbg !7 {<br class="">+entry:<br class="">+ %0 = zext i32 %n to i64, !dbg !11<br class="">+ %1 = call i8* @llvm.stacksave(), !dbg !12<br class="">+ call void @llvm.dbg.value(metadata i64 %0, metadata !13, metadata !DIExpression()), !dbg !12<br class="">+ %vla.i = alloca i32, i64 %0, align 16, !dbg !12<br class="">+ call void @llvm.stackrestore(i8* %1), !dbg !12<br class="">+ ret void, !dbg !12<br class="">+}<br class="">+<br class="">+; Function Attrs: nounwind<br class="">+declare i8* @llvm.stacksave() #1<br class="">+<br class="">+; Function Attrs: nounwind<br class="">+declare void @llvm.stackrestore(i8*) #1<br class="">+<br class="">+; Function Attrs: nounwind readnone speculatable<br class="">+declare void @llvm.dbg.value(metadata, metadata, metadata) #2<br class="">+<br class="">+attributes #0 = { noinline nounwind optnone uwtable }<br class="">+attributes #1 = { nounwind }<br class="">+attributes #2 = { nounwind readnone speculatable }<br class="">+<br class="">+!llvm.dbg.cu = !{!0}<br class="">+!llvm.module.flags = !{!3, !4, !5}<br class="">+!llvm.ident = !{!6}<br class="">+<br class="">+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 7.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)<br class="">+!1 = !DIFile(filename: "foo.c", directory: "/path/to/build")<br class="">+!2 = !{}<br class="">+!3 = !{i32 2, !"Dwarf Version", i32 4}<br class="">+!4 = !{i32 2, !"Debug Info Version", i32 3}<br class="">+!5 = !{i32 1, !"wchar_size", i32 4}<br class="">+!6 = !{!"clang version 7.0.0"}<br class="">+!7 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 1, type: !8, isLocal: false, isDefinition: true, scopeLine: 39, isOptimized: false, unit: !0, variables: !2)<br class="">+!8 = !DISubroutineType(types: !9)<br class="">+!9 = !{!10}<br class="">+!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)<br class="">+!11 = !DILocation(line: 2, column: 5, scope: !7)<br class="">+!12 = !DILocation(line: 4, column: 5, scope: !7)<br class="">+!13 = !DILocalVariable(name: "__vla_expr", scope: !14, type: !15, flags: DIFlagArtificial)<br class="">+!14 = distinct !DILexicalBlock(scope: !7, file: !1, line: 32, column: 31)<br class="">+!15 = !DIBasicType(name: "long unsigned int", size: 64, encoding: DW_ATE_unsigned)<br class="">Modified: llvm/trunk/test/DebugInfo/X86/fission-ranges.ll<br class="">URL:<span class="Apple-converted-space"> </span></span><a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/X86/fission-ranges.ll?rev=325438&r1=325437&r2=325438&view=diff" style="color: purple; text-decoration: underline;" class=""><span class="">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/X86/fission-ranges.ll?rev=325438&r1=325437&r2=325438&view=diff</span><span class=""></span></a><span class=""><br class="">==============================================================================<br class="">--- llvm/trunk/test/DebugInfo/X86/fission-ranges.ll (original)<br class="">+++ llvm/trunk/test/DebugInfo/X86/fission-ranges.ll Sat Feb 17 08:42:54 2018<br class="">@@ -17,6 +17,7 @@<br class="">; CHECK: DW_AT_location [DW_FORM_sec_offset] ([[B:0x[0-9a-z]*]]<br class="">; CHECK: DW_AT_location [DW_FORM_sec_offset] ([[D:0x[0-9a-z]*]]<br class="">; CHECK: DW_AT_ranges [DW_FORM_sec_offset] (0x00000000<br class="">+; CHECK: DW_AT_location [DW_FORM_sec_offset] ([[W:0x[0-9a-z]*]]<br class="">; CHECK-NOT: .debug_loc contents:<br class="">; CHECK-NOT: Beginning address offset<br class="">; CHECK: .debug_loc.dwo contents:<br class="">@@ -25,24 +26,27 @@<br class="">; if they've changed due to a bugfix, change in register allocation, etc.<br class="">; CHECK: [[A]]:<br class="">-; CHECK-NEXT: Addr idx 2 (w/ length 169): DW_OP_consts +0, DW_OP_stack_value<br class="">+; CHECK-NEXT: Addr idx 2 (w/ length 188): DW_OP_consts +0, DW_OP_stack_value<br class="">; CHECK-NEXT: Addr idx 3 (w/ length 25): DW_OP_reg0 RAX<br class="">+; CHECK: [[W]]:<br class="">+; CHECK-NEXT: Addr idx 4 (w/ length 20): DW_OP_reg1 RDX<br class="">+; CHECK-NEXT: Addr idx 5 (w/ length 102): DW_OP_breg7 RSP-56<br class="">; CHECK: [[E]]:<br class="">-; CHECK-NEXT: Addr idx 4 (w/ length 19): DW_OP_reg0 RAX<br class="">+; CHECK-NEXT: Addr idx 6 (w/ length 24): DW_OP_reg0 RAX<br class="">; CHECK: [[B]]:<br class="">-; CHECK-NEXT: Addr idx 5 (w/ length 17): DW_OP_reg0 RAX<br class="">+; CHECK-NEXT: Addr idx 7 (w/ length 17): DW_OP_reg0 RAX<br class="">; CHECK: [[D]]:<br class="">-; CHECK-NEXT: Addr idx 6 (w/ length 17): DW_OP_reg0 RAX<br class="">+; CHECK-NEXT: Addr idx 8 (w/ length 21): DW_OP_reg0 RAX<br class=""> ; Make sure we don't produce any relocations in any .dwo section (though in particular, debug_info.dwo)<br class="">; HDR-NOT: .rela.{{.*}}.dwo<br class="">; Make sure we have enough stuff in the debug_addr to cover the address indexes<br class="">-; (6 is the last index in debug_loc.dwo, making 7 entries of 8 bytes each, 7 * 8<br class="">-; == 56 base 10 == 38 base 16)<br class="">+; (8 is the last index in debug_loc.dwo, making 9 entries of 8 bytes each, 9 * 8<br class="">+; == 72 base 10 == 48 base 16)<br class="">-; HDR: .debug_addr 00000038<br class="">+; HDR: .debug_addr 00000048<br class="">; HDR-NOT: .rela.{{.*}}.dwo<br class="">; From the code:<br class="">_______________________________________________<br class="">llvm-commits mailing list<br class=""></span><a href="mailto:llvm-commits@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">llvm-commits@lists.llvm.org</span><span class=""></span></a><span class=""><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" style="color: purple; text-decoration: underline;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p class=""></o:p></span></div></blockquote><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><reduced.ll>_______________________________________________<br class="">llvm-commits mailing list<br class=""></span><a href="mailto:llvm-commits@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">llvm-commits@lists.llvm.org</span><span class=""></span></a><span class=""><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" style="color: purple; text-decoration: underline;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p class=""></o:p></span></div></blockquote><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class="">_______________________________________________<br class="">llvm-commits mailing list<br class=""></span><a href="mailto:llvm-commits@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">llvm-commits@lists.llvm.org</span><span class=""></span></a><span class=""><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" style="color: purple; text-decoration: underline;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p class=""></o:p></span></div></blockquote><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></blockquote><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class=""><br class=""><br class="">IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.<o:p class=""></o:p></span></div></div></div></blockquote></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.</span></blockquote></div><br class=""></div></body></html>