<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.xapple-converted-space
{mso-style-name:x_apple-converted-space;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We might also consider revisiting the tactic of FastISel iterating through the block in reverse order. The idea there was to be able to reuse values that had
to be explicitly materialized into registers. However it's not clear to me how much of a win this is, given that in some cases it might actually force spilling and reloading those registers. And the reverse iteration has caused problems with debug info before.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-commits [mailto:llvm-commits-bounces@lists.llvm.org]
<b>On Behalf Of </b>Vedant Kumar via llvm-commits<br>
<b>Sent:</b> Thursday, February 22, 2018 11:18 AM<br>
<b>To:</b> Vedant Kumar<br>
<b>Cc:</b> llvm-commits<br>
<b>Subject:</b> Re: [llvm] r325438 - [DebugInfo][FastISel] Fix dropping dbg.value()<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Ah, I attached the skipUnlessSwiftPR patch by mistake, sorry. This is the correct patch for <a href="https://reviews.llvm.org/D43427">D43427</a>:
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">vedant<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Feb 22, 2018, at 11:14 AM, Vedant Kumar via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Hi Sander,</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Feb 22, 2018, at 9:46 AM, Sander De Smalen <<a href="mailto:Sander.DeSmalen@arm.com">Sander.DeSmalen@arm.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Hi Vedant,<br>
<br>
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></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> ... = add i32 %X, %W<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> ... = add i32 %Y, %Z<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> DBG_VAL %X<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I'm happy to be wrong about this, though, as that would make life much simpler :).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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">https://reviews.llvm.org/D43427</a> improves
an end-to-end test I've got.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><0001-FastISel-Try-lowering-dbg.value-instructions-twice-W.patch>
<o:p></o:p></p>
<p class="MsoNormal"><0001-test-Introduce-the-skipUnlessSwiftPR-decorator.patch> <o:p>
</o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I'm fine reverting the patch for now though.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Right, I think that would be best for now -- at least to resolve the assertion failure.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">thanks!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">vedant<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Sander<br>
<br>
<br>
On 21/02/2018, 23:51, "<a href="mailto:vsk@apple.com">vsk@apple.com</a><span class="xapple-converted-space"> </span>on behalf of Vedant Kumar" <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
<br>
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>
<br>
@Sander, should we revert this change until we have a solution?<br>
<br>
vedant<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Feb 21, 2018, at 2:56 PM, Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
<br>
Here's a possible fix:<br>
<br>
diff --git a/include/llvm/CodeGen/FastISel.h b/include/llvm/CodeGen/FastISel.h<br>
index 85bb826dcb8..251d76369fc 100644<br>
--- a/include/llvm/CodeGen/FastISel.h<br>
+++ b/include/llvm/CodeGen/FastISel.h<br>
@@ -262,9 +262,10 @@ public:<br>
/// to the current block. Return true if selection was successful.<br>
bool selectOperator(const User *I, unsigned Opcode);<br>
<br>
- /// \brief Create a virtual register and arrange for it to be assigned the<br>
- /// value for the given LLVM value.<br>
- unsigned getRegForValue(const Value *V);<br>
+ /// \brief Create or look up a virtual register and arrange for it to be<br>
+ /// assigned the value for the given LLVM value. A virtual register may only<br>
+ /// be created if \p AllowMaterialize is true.<br>
+ unsigned getRegForValue(const Value *V, bool AllowMaterialize = true);<br>
<br>
/// \brief Look up the value to see if its value is already cached in a<br>
/// register. It may be defined by instructions across blocks or defined<br>
diff --git a/lib/CodeGen/SelectionDAG/FastISel.cpp b/lib/CodeGen/SelectionDAG/FastISel.cpp<br>
index 686fe88a2be..7270aeb25b2 100644<br>
--- a/lib/CodeGen/SelectionDAG/FastISel.cpp<br>
+++ b/lib/CodeGen/SelectionDAG/FastISel.cpp<br>
@@ -192,7 +192,7 @@ bool FastISel::hasTrivialKill(const Value *V) {<br>
cast<Instruction>(*I->user_begin())->getParent() == I->getParent();<br>
}<br>
<br>
-unsigned FastISel::getRegForValue(const Value *V) {<br>
+unsigned FastISel::getRegForValue(const Value *V, bool AllowMaterialize) {<br>
EVT RealVT = TLI.getValueType(DL, V->getType(), /*AllowUnknown=*/true);<br>
// Don't handle non-simple values in FastISel.<br>
if (!RealVT.isSimple())<br>
@@ -216,12 +216,18 @@ unsigned FastISel::getRegForValue(const Value *V) {<br>
return Reg;<br>
<br>
// In bottom-up mode, just create the virtual register which will be used<br>
- // to hold the value. It will be materialized later.<br>
+ // to hold the value. It will be materialized later if it has uses.<br>
if (isa<Instruction>(V) &&<br>
(!isa<AllocaInst>(V) ||<br>
- !FuncInfo.StaticAllocaMap.count(cast<AllocaInst>(V))))<br>
+ !FuncInfo.StaticAllocaMap.count(cast<AllocaInst>(V))) &&<br>
+ (AllowMaterialize || !V->use_empty()))<br>
return FuncInfo.InitializeRegForValue(V);<br>
<br>
+ // If we're not allowed to materialize a value (say, because it's a debug<br>
+ // value), bail out now.<br>
+ if (!AllowMaterialize)<br>
+ return 0;<br>
+<br>
SavePoint SaveInsertPt = enterLocalValueArea();<br>
<br>
// Materialize the value in a register. Emit any instructions in the<br>
@@ -1235,7 +1241,7 @@ bool FastISel::selectIntrinsicCall(const IntrinsicInst *II) {<br>
.addImm(0U)<br>
.addMetadata(DI->getVariable())<br>
.addMetadata(DI->getExpression());<br>
- } else if (unsigned Reg = getRegForValue(V)) {<br>
+ } else if (unsigned Reg = getRegForValue(V, /*AllowMaterialize=*/false)) {<br>
// FIXME: This does not handle register-indirect values at offset 0.<br>
bool IsIndirect = false;<br>
BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc, II, IsIndirect, Reg,<br>
<br>
vedant<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Feb 21, 2018, at 2:40 PM, Vedant Kumar via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
<br>
You can reduce this even further by running `opt -strip -metarenamer -debugify` on the file Mikael attached:<br>
<br>
<reduced.ll><br>
<br>
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>
<br>
vedant<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Feb 21, 2018, at 3:53 AM, Mikael Holmén via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
<br>
Hi Sander,<br>
<br>
I stumbled upon a case that hits an assert with this patch:<br>
<br>
llc -O0 -mtriple x86_64-unknown-linux-gnu -mcpu=x86-64 -o - reduced.ll<br>
<br>
gives<br>
<br>
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>
#0 0x0000000001e85f04 PrintStackTraceSignalHandler(void*) (build-all/bin/llc+0x1e85f04)<br>
#1 0x0000000001e86676 SignalHandler(int) (build-all/bin/llc+0x1e86676)<br>
#2 0x00007f3824026330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)<br>
#3 0x00007f3822c15c37 gsignal /build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0<br>
#4 0x00007f3822c19028 abort /build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0<br>
#5 0x00007f3822c0ebf6 __assert_fail_base /build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0<br>
#6 0x00007f3822c0eca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)<br>
#7 0x0000000001cb1492 llvm::SelectionDAGBuilder::CopyToExportRegsIfNeeded(llvm::Value const*) (build-all/bin/llc+0x1cb1492)<br>
#8 0x0000000001cb06e8 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) (build-all/bin/llc+0x1cb06e8)<br>
#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>
#10 0x0000000001d4a501 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (build-all/bin/llc+0x1d4a501)<br>
#11 0x0000000001d467e7 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build-all/bin/llc+0x1d467e7)<br>
#12 0x000000000112c011 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build-all/bin/llc+0x112c011)<br>
#13 0x00000000015f3659 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (build-all/bin/llc+0x15f3659)<br>
#14 0x00000000018fa2b8 llvm::FPPassManager::runOnFunction(llvm::Function&) (build-all/bin/llc+0x18fa2b8)<br>
#15 0x00000000018fa4f8 llvm::FPPassManager::runOnModule(llvm::Module&) (build-all/bin/llc+0x18fa4f8)<br>
#16 0x00000000018fa9d5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all/bin/llc+0x18fa9d5)<br>
#17 0x00000000006d9305 compileModule(char**, llvm::LLVMContext&) (build-all/bin/llc+0x6d9305)<br>
#18 0x00000000006d6a7b main (build-all/bin/llc+0x6d6a7b)<br>
#19 0x00007f3822c00f45 __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0<br>
#20 0x00000000006d427d _start (build-all/bin/llc+0x6d427d)<br>
Stack dump:<br>
0. Program arguments: build-all/bin/llc -O0 -mtriple x86_64-unknown-linux-gnu -mcpu=x86-64 -o - reduced.ll<br>
1. Running pass 'Function Pass Manager' on module 'reduced.ll'.<br>
2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@func_11'<br>
<br>
Regards,<br>
Mikael<br>
<br>
On 02/17/2018 05:42 PM, Sander de Smalen via llvm-commits wrote:<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Author: s.desmalen<br>
Date: Sat Feb 17 08:42:54 2018<br>
New Revision: 325438<br>
URL:<span class="xapple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project?rev=325438&view=rev">http://llvm.org/viewvc/llvm-project?rev=325438&view=rev</a><br>
Log:<br>
[DebugInfo][FastISel] Fix dropping dbg.value()<br>
Summary:<br>
<a href="https://llvm.org/PR36263">https://llvm.org/PR36263</a><span class="xapple-converted-space"> </span>shows that when compiling at -O0 a dbg.value()<br>
instruction (that remains from an original dbg.declare()) is dropped<br>
by FastISel. Since FastISel selects instructions by iterating a basic<br>
block backwards, it drops the dbg.value if one of its operands is not<br>
yet instantiated by a previously selected instruction.<br>
Instead of calling 'lookUpRegForValue()' we can call 'getRegForValue()'<br>
instead that will insert a placeholder for the operand to be filled in<br>
when continuing the instruction selection.<br>
Reviewers: aprantl, dblaikie, probinson<br>
Reviewed By: aprantl<br>
Subscribers: llvm-commits, dstenb, JDevlieghere<br>
Differential Revision:<span class="xapple-converted-space"> </span><a href="https://reviews.llvm.org/D43386">https://reviews.llvm.org/D43386</a><br>
Added:<br>
llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll<br>
Modified:<br>
llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp<br>
llvm/trunk/test/DebugInfo/X86/fission-ranges.ll<br>
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp<br>
URL:<span class="xapple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp?rev=325438&r1=325437&r2=325438&view=diff">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp?rev=325438&r1=325437&r2=325438&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp (original)<br>
+++ llvm/trunk/lib/CodeGen/SelectionDAG/FastISel.cpp Sat Feb 17 08:42:54 2018<br>
@@ -1235,7 +1235,7 @@ bool FastISel::selectIntrinsicCall(const<br>
.addImm(0U)<br>
.addMetadata(DI->getVariable())<br>
.addMetadata(DI->getExpression());<br>
- } else if (unsigned Reg = lookUpRegForValue(V)) {<br>
+ } else if (unsigned Reg = getRegForValue(V)) {<br>
// FIXME: This does not handle register-indirect values at offset 0.<br>
bool IsIndirect = false;<br>
BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc, II, IsIndirect, Reg,<br>
Added: llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll<br>
URL:<span class="xapple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll?rev=325438&view=auto">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll?rev=325438&view=auto</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll (added)<br>
+++ llvm/trunk/test/CodeGen/Generic/dbg_value_fastisel.ll Sat Feb 17 08:42:54 2018<br>
@@ -0,0 +1,54 @@<br>
+; RUN: llc -O0 -stop-after=livedebugvalues -fast-isel=true < %s | FileCheck %s<br>
+<br>
+; CHECK: ![[LOCAL:[0-9]+]] = !DILocalVariable(name: "__vla_expr",<br>
+; CHECK: DBG_VALUE {{.*}} ![[LOCAL]]<br>
+<br>
+; ModuleID = '<stdin>'<br>
+source_filename = "foo.c"<br>
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"<br>
+target triple = "x86_64-unknown-linux-gnu"<br>
+<br>
+; Function Attrs: noinline nounwind optnone uwtable<br>
+define void @foo(i32 %n) local_unnamed_addr #0 !dbg !7 {<br>
+entry:<br>
+ %0 = zext i32 %n to i64, !dbg !11<br>
+ %1 = call i8* @llvm.stacksave(), !dbg !12<br>
+ call void @llvm.dbg.value(metadata i64 %0, metadata !13, metadata !DIExpression()), !dbg !12<br>
+ %vla.i = alloca i32, i64 %0, align 16, !dbg !12<br>
+ call void @llvm.stackrestore(i8* %1), !dbg !12<br>
+ ret void, !dbg !12<br>
+}<br>
+<br>
+; Function Attrs: nounwind<br>
+declare i8* @llvm.stacksave() #1<br>
+<br>
+; Function Attrs: nounwind<br>
+declare void @llvm.stackrestore(i8*) #1<br>
+<br>
+; Function Attrs: nounwind readnone speculatable<br>
+declare void @llvm.dbg.value(metadata, metadata, metadata) #2<br>
+<br>
+attributes #0 = { noinline nounwind optnone uwtable }<br>
+attributes #1 = { nounwind }<br>
+attributes #2 = { nounwind readnone speculatable }<br>
+<br>
+!llvm.dbg.cu = !{!0}<br>
+!llvm.module.flags = !{!3, !4, !5}<br>
+!llvm.ident = !{!6}<br>
+<br>
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 7.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)<br>
+!1 = !DIFile(filename: "foo.c", directory: "/path/to/build")<br>
+!2 = !{}<br>
+!3 = !{i32 2, !"Dwarf Version", i32 4}<br>
+!4 = !{i32 2, !"Debug Info Version", i32 3}<br>
+!5 = !{i32 1, !"wchar_size", i32 4}<br>
+!6 = !{!"clang version 7.0.0"}<br>
+!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>
+!8 = !DISubroutineType(types: !9)<br>
+!9 = !{!10}<br>
+!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)<br>
+!11 = !DILocation(line: 2, column: 5, scope: !7)<br>
+!12 = !DILocation(line: 4, column: 5, scope: !7)<br>
+!13 = !DILocalVariable(name: "__vla_expr", scope: !14, type: !15, flags: DIFlagArtificial)<br>
+!14 = distinct !DILexicalBlock(scope: !7, file: !1, line: 32, column: 31)<br>
+!15 = !DIBasicType(name: "long unsigned int", size: 64, encoding: DW_ATE_unsigned)<br>
Modified: llvm/trunk/test/DebugInfo/X86/fission-ranges.ll<br>
URL:<span class="xapple-converted-space"> </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">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/X86/fission-ranges.ll?rev=325438&r1=325437&r2=325438&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/DebugInfo/X86/fission-ranges.ll (original)<br>
+++ llvm/trunk/test/DebugInfo/X86/fission-ranges.ll Sat Feb 17 08:42:54 2018<br>
@@ -17,6 +17,7 @@<br>
; CHECK: DW_AT_location [DW_FORM_sec_offset] ([[B:0x[0-9a-z]*]]<br>
; CHECK: DW_AT_location [DW_FORM_sec_offset] ([[D:0x[0-9a-z]*]]<br>
; CHECK: DW_AT_ranges [DW_FORM_sec_offset] (0x00000000<br>
+; CHECK: DW_AT_location [DW_FORM_sec_offset] ([[W:0x[0-9a-z]*]]<br>
; CHECK-NOT: .debug_loc contents:<br>
; CHECK-NOT: Beginning address offset<br>
; CHECK: .debug_loc.dwo contents:<br>
@@ -25,24 +26,27 @@<br>
; if they've changed due to a bugfix, change in register allocation, etc.<br>
; CHECK: [[A]]:<br>
-; CHECK-NEXT: Addr idx 2 (w/ length 169): DW_OP_consts +0, DW_OP_stack_value<br>
+; CHECK-NEXT: Addr idx 2 (w/ length 188): DW_OP_consts +0, DW_OP_stack_value<br>
; CHECK-NEXT: Addr idx 3 (w/ length 25): DW_OP_reg0 RAX<br>
+; CHECK: [[W]]:<br>
+; CHECK-NEXT: Addr idx 4 (w/ length 20): DW_OP_reg1 RDX<br>
+; CHECK-NEXT: Addr idx 5 (w/ length 102): DW_OP_breg7 RSP-56<br>
; CHECK: [[E]]:<br>
-; CHECK-NEXT: Addr idx 4 (w/ length 19): DW_OP_reg0 RAX<br>
+; CHECK-NEXT: Addr idx 6 (w/ length 24): DW_OP_reg0 RAX<br>
; CHECK: [[B]]:<br>
-; CHECK-NEXT: Addr idx 5 (w/ length 17): DW_OP_reg0 RAX<br>
+; CHECK-NEXT: Addr idx 7 (w/ length 17): DW_OP_reg0 RAX<br>
; CHECK: [[D]]:<br>
-; CHECK-NEXT: Addr idx 6 (w/ length 17): DW_OP_reg0 RAX<br>
+; CHECK-NEXT: Addr idx 8 (w/ length 21): DW_OP_reg0 RAX<br>
; Make sure we don't produce any relocations in any .dwo section (though in particular, debug_info.dwo)<br>
; HDR-NOT: .rela.{{.*}}.dwo<br>
; Make sure we have enough stuff in the debug_addr to cover the address indexes<br>
-; (6 is the last index in debug_loc.dwo, making 7 entries of 8 bytes each, 7 * 8<br>
-; == 56 base 10 == 38 base 16)<br>
+; (8 is the last index in debug_loc.dwo, making 9 entries of 8 bytes each, 9 * 8<br>
+; == 72 base 10 == 48 base 16)<br>
-; HDR: .debug_addr 00000038<br>
+; HDR: .debug_addr 00000048<br>
; HDR-NOT: .rela.{{.*}}.dwo<br>
; From the code:<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><reduced.ll>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<br>
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></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">_______________________________________________<br>
llvm-commits mailing list<br>
</span><a href="mailto:llvm-commits@lists.llvm.org"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">llvm-commits@lists.llvm.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
</span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>