<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Parameter location list unnecessarily complex when value available in multiple regs"
href="https://bugs.llvm.org/show_bug.cgi?id=42834">42834</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Parameter location list unnecessarily complex when value available in multiple regs
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vsk@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=22319" name="attach_22319" title="MIR reproducer">attachment 22319</a> <a href="attachment.cgi?id=22319&action=edit" title="MIR reproducer">[details]</a></span>
MIR reproducer
A value may be available in multiple locations simultaneously. However, llvm
does not always emit a minimal location list in this situation.
Consider the attached IR/MIR (cgscc-func.mir). The parameter “V” is never
modified, and is almost-always available in both $rdi and $rax. However, the
location list looks like:
0x000510ce: DW_TAG_formal_parameter
DW_AT_location (0x00000c78
[0x0000000100002730, 0x000000010000273c): DW_OP_reg5 RDI
[0x000000010000273c, 0x0000000100002746): DW_OP_reg0 RAX
[0x0000000100002746, 0x0000000100002748):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
[0x0000000100002748, 0x000000010000275f): DW_OP_reg0 RAX
[0x000000010000275f, 0x0000000100002765):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
[0x0000000100002765, 0x000000010000276d): DW_OP_reg0 RAX
[0x000000010000276d, 0x0000000100002773):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
[0x0000000100002773, 0x000000010000277b): DW_OP_reg0 RAX
[0x000000010000277b, 0x000000010000277d):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
[0x000000010000277d, 0x0000000100002784): DW_OP_reg5 RDI
[0x0000000100002784, 0x000000010000279c):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
[0x000000010000279c, 0x00000001000027bb): DW_OP_reg0 RAX
[0x00000001000027bb, 0x00000001000027bb):
DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
DW_AT_name ("V")
This alternative seems better:
0x000510ce: DW_TAG_formal_parameter
DW_AT_location (0x00000c78
[0x0000000100002730, 0x00000001000027bb): DW_OP_reg5 RDI)
DW_AT_name ("V")
Notes:
After the following COPY is inserted, the DBG_VALUEs for “V” tend to point to
%5 ($rax):
bb.0.entry:
successors: %bb.1(0x00000001), %bb.2(0x7fffffff); %bb.1(0.00%),
%bb.2(100.00%)
liveins: $rdi
DBG_VALUE $rdi, $noreg, !"V", !DIExpression(), debug-location !51604
%5:gr64_with_sub_8bit = COPY $rdi
DBG_VALUE %5:gr64_with_sub_8bit, $noreg, !"V", !DIExpression(),
debug-location !51604
I’m not sure whether it’s worth tracking all locations for all values in the
general case (I doubt it). But for this specific case, maybe we can avoid
emitting the DBG_VALUE for $rax until $rdi is actually clobbered.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>