[llvm-bugs] [Bug 42834] New: Parameter location list unnecessarily complex when value available in multiple regs

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42834

            Bug ID: 42834
           Summary: Parameter location list unnecessarily complex when
                    value available in multiple regs
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vsk at apple.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Created attachment 22319
  --> https://bugs.llvm.org/attachment.cgi?id=22319&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190730/4e1c7af5/attachment.html>