[llvm-bugs] [Bug 32288] New: Unnecessary narrowing of register reference in DW_AT_location for int parameter

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=32288

            Bug ID: 32288
           Summary: Unnecessary narrowing of register reference in
                    DW_AT_location for int parameter
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: dblaikie at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18099
  --> http://bugs.llvm.org/attachment.cgi?id=18099&action=edit
repro IR

Given:

  void f(int i) { }

(which produces the attached LLVM IR)

The DWARF generated by LLVM includes this location:

  0x55 0x93 0x04
  DW_OP_reg5 DW_OP_piece(4)

When GCC's DWARF is simply 0x55 (DW_OP_reg5) without the DW_OP_piece. I believe
it's reasonable to assume the DWARF consumer knows which part of a register
logically holds the value (low bytes, high bytes, how many bytes, etc) for a
primitive value like an integer.

If something fancy is going on, like the register only contains part of an
object (eg: struct foo { int x, y, z; }; gets {reg5, piece(8), reg4, piece(4)}
which is probably important ({reg5, reg4} seems inadequate) - interestingly,
GCC uses fbreg (insufficient optimization?) even at -O3)

PR33269 has some related work.

This could be changed in DwarfExpression::setSubRegisterPiece could be a no-op
when the offset is zero? (But this wouldn't be quite right for a case where
that piece was used as part of a larger value, perhaps... as in the 'foo'
example above)

-- 
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/20170315/b8aebe5f/attachment.html>