[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