[LLVMdev] [PROPOSAL] Attach debugging information with LLVM instruction

Chris Lattner clattner at apple.com
Thu Sep 10 13:14:24 PDT 2009


On Sep 10, 2009, at 10:48 AM, Devang Patel wrote:

> Hi All,
>
> Today, debugging information is encoded in LLVM IR using various
> llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple,

Right.

> This approach has several disadvantages.
> - The llvm.dbg.stoppoint()s act like hurdles to the optimizer. The
> LLVM customers expect that the optimizer does not trip over these
> hurdles. They expect LLVM to produce same high quality code
> irrespective of the presence of debug info. It is a tedious and never
> ending task to ensure that the optimizer safely ignores these llvm.dbg
> intrinsics.

This is not a problem with stoppoints.  Even after we eliminate  
stoppoints, we'll still have the same thing for other debug info.

> - The instructions lose original location info when the optimizer
> moves them around.
> - It is extremely error prone to keep track of lexical scopes and
> inlined functions using a pair of llvm.dbg intrinsics.

Right.

> The proposed solution is to optionally attach debug information with
> llvm instruction directly. A new keyword 'dbg' is used to identify
> debugging information associated with an instruction. The debugging
> information, if available, is printed after the last instruction
> operand. The debugging information entry uses MDNode and it is not
> counted as an instruction operand. For example,
>
> !1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata
> !"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32
> 0}
> !7 = metadata !{i32 5, i32 5, metadata !1, metadata !1}
> !8 = metadata !{i32 6, i32 5, metadata !1, metadata !1}
>
>  ...
>  store i32 42, i32* %i, dbg metadata !7
>  store i32 1, i32* %j.addr, dbg metadata !8
>  br label %if.end, dbg metadata !8
>  ...

Instead of 'dbg metadata !7', is it sufficient to have 'dbg !7'?

I think this is a pretty reasonable syntax, we can even get the  
asmprinter to handle this as a special case and print it as:

store i32 42, i32* %i, dbg metadata !{i32 5, i32 5, metadata !1,  
metadata !1}

which makes it easier to read.

> Now, the optimizer does not need to worry about those llvm.dbg
> hurdles. Instructions do not lose their location information when they
> are rearranged in instruction stream. And the stage is set to produce,
> preserve and emit accurate debug information for inlined functions.

Sounds nice!

-Chris



More information about the llvm-dev mailing list