[llvm-bugs] [Bug 30703] New: SROA sometimes breaks local variable debuginfo that uses DIExpression

[via llvm-bugs]

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

            Bug ID: 30703
           Summary: SROA sometimes breaks local variable debuginfo that
                    uses DIExpression
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: michaelwoerister at posteo.net
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

In the Rust compiler, closures are translated into regular functions with the
closure environment passed in as the first function parameter. These
environments are structs containing the variables that have been captured by
the closure. Each captured variable can either be contained in the environment
struct directly (by value), or the environment contains a pointer to where the
captured variable actually lives.

When generating debuginfo for closures, we want captured variables to appear
like regular locals. To this end we use a `@llvm.dbg.declare()` that points to
the alloca containing the environment struct and that has a DIExpression
navigating to field in question (via a DW_OP_plus) and, if needed, doing a
DW_OP_deref. This works well in most cases, but sometimes SROA will produce
bitcode that fails verification with an error like:

piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata { i8*, i64 }* %arg0.sroa.5.0.copyload, i64
0, metadata !361, metadata !370), !dbg !368
!361 = !DILocalVariable(name: "buf", scope: !313, file: !30, line: 1, type:
!341)
!370 = !DIExpression(DW_OP_bit_piece, 128, 64)

So far, we have been able to work around this by always creating an additional
alloca containing a pointer to the environment struct and then using that as
the starting point for computing the variables' location in the DIExpression.
SROA seems to be able to handle this case in a more reliable way. However, we'd
like to get rid of this additional alloca that is just introduced for the sake
of debuginfo.

We have managed to create a rather small test case for reproducing this:
https://gist.github.com/michaelwoerister/55aed8d38be97c404b31c091cbb37ebd

bugpoint reduced this further (it fails for a different variable there, one
that does not have a DW_OP_plus, but with the same assertion):
https://gist.github.com/michaelwoerister/8dba37e51a4dc17413229770081d2c76

-- 
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/20161014/1cb5d2a3/attachment.html>