search for: inlinedat

...lo, A few days ago I upgraded to the LLVM/clang ToT (on Jan 19th or so) and I just encountered this assertion. “Expected to drop a reference” which is defined in llvm/lib/IR/Metadata.cpp line 136. I create DebugLoc objects using DebugLog:get(unsigned line, unsigned Col, MDNode *Scope, MDNode *InlinedAt=nullptr) The DebugLoc objects are wrapped in one of my classes and when instances get destructed the assertion is thrown. Would anyone have an idea what I’m doing wrong that causes this? Best, Christian Schafmeister Professor Chemistry Department Temple University

(I think I've asked a similar question off-list a couple of times, but never got an answer) Hi folks, For [K]MSAN we need to figure out which inlined function a local var originally belonged to in the source file. E.g. when a local buffer %buf is declared in @bar(), but @bar() is inlined into @foo(), then there's a local %buf.i in @foo(), but we need to determine that the local came from

On Aug 31, 2010, at 9:03 AM, Talin wrote: > 4) What is the meaning of the "inlinedAt" argument for DebugLoc::get()? Does it mean the location where the inlined code was defined, or the location where it was expanded? the location where it was expanded - Devang

...metadata !10, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 1024)), !dbg !18 call void @llvm.dbg.declare(metadata [32 x i32]* %b.sroa.4.i, metadata !10, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 1024)), !dbg !20 The dbg.declares are identical except that !18 and !20 have different inlinedAt fields. The above is the result of the alloca-merging done by the inliner. After inlining two calls to the same function it merges two allocas and keeps the dbg.declares from each of them. On 09/19/2017 05:44 PM, Reid Kleckner wrote: > I think it's a bug in both places: the backend shoul...

> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.

...related() !dbg !4 { ret void, !dbg !11 } !1 = distinct !DISubprogram(name: "foo") !2 = distinct !DISubprogram(name: "caller1") !3 = distinct !DISubprogram(name: "caller2") !4 = distinct !DISubprogram(name: "unrelated") !5 = !DILocation(line: 2, scope: !1, inlinedAt: !6) !6 = distinct !DILocation(line: 3, scope: !2) !7 = !DILocation(line: 3, scope: !2) !8 = !DILocation(line: 2, scope: !1, inlinedAt: !9) !9 = distinct !DILocation(line: 4, scope: !3) !10 = !DILocation(line: 4, scope: !3) !11 = !DILocation(line: 5, scope: !4) -- In this example, !1 (subprogram...

...a scope which is a DISubprogram, where that subprogram's DIFile is the file from where the code was defined. However, if the code didn't come from a function but was synthesized by the compiler, then I'm not sure how to generate a valid DISubprogram. 4) What is the meaning of the "inlinedAt" argument for DebugLoc::get()? Does it mean the location where the inlined code was defined, or the location where it was expanded? -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100831/e0...

...11 > } > > !1 = distinct !DISubprogram(name: "foo") > !2 = distinct !DISubprogram(name: "caller1") > !3 = distinct !DISubprogram(name: "caller2") > !4 = distinct !DISubprogram(name: "unrelated") > > !5 = !DILocation(line: 2, scope: !1, inlinedAt: !6) > !6 = distinct !DILocation(line: 3, scope: !2) > !7 = !DILocation(line: 3, scope: !2) > > !8 = !DILocation(line: 2, scope: !1, inlinedAt: !9) > !9 = distinct !DILocation(line: 4, scope: !3) > !10 = !DILocation(line: 4, scope: !3) > > !11 = !DILocation(line: 5, scope: !...

...block instead of intrinsic. > > https://reviews.llvm.org/D45078 In this revised design it is now possible to attach a DILabel to a BasicBlock. When the basic block is inlined it will be ambiguous to which function the DILabel belongs. For instructions, we store the inline information in the inlinedAt: field of its DILocation. In order to handle inlining for DILabels we have two options: 1. Also attach a DILocation to be associated with the label to carry the inline information, and teach the inliner to correctly update the DILocation on basic blocks during inlining. This would also solve the...

...> } > > !1 = distinct !DISubprogram(name: "foo") > !2 = distinct !DISubprogram(name: "caller1") > !3 = distinct !DISubprogram(name: "caller2") > !4 = distinct !DISubprogram(name: "unrelated") > > !5 = !DILocation(line: 2, scope: !1, inlinedAt: !6) > !6 = distinct !DILocation(line: 3, scope: !2) > !7 = !DILocation(line: 3, scope: !2) > > !8 = !DILocation(line: 2, scope: !1, inlinedAt: !9) > !9 = distinct !DILocation(line: 4, scope: !3) > !10 = !DILocation(line: 4, scope: !3) > > !11 = !DILocation(line: 5, scope:...

...n as the debug intrinsic. Does anyone have an idea why this isn't so? Right now one needs to build a mapping between AllocaInst and llvm.dbg.declare() in order to get the debug info for the allocation. > if you want to find the function that it was inlined *into* then you need to follow the inlinedAt link in the DILoation. > > -- adrian > > > E.g. when a local buffer %buf is declared in @bar(), but @bar() is > > inlined into @foo(), then there's a local %buf.i in @foo(), but we > > need to determine that the local came from @bar(). In the case of > > nested...

...getsiginfo()) The last three intrinsics indeed point to line 888, where |siginfo| is declared. Is the DW_OP_deref tag enough to distinguish the right llvm.dbg.value? > -- adrian > > > > >> if you want to find the function that it was inlined *into* then you need to follow the inlinedAt link in the DILoation. > >> > >> -- adrian > >> > >>> E.g. when a local buffer %buf is declared in @bar(), but @bar() is > >>> inlined into @foo(), then there's a local %buf.i in @foo(), but we > >>> need to determine that the local...

...t; >> unsigned getLine() const { return Line; } >> unsigned getColumn() const { return Column; } >> bool isInlined() const { return getNumOperands() == 2; } >> MDNode *getScope() const { return getOperand(0); } >> MDNode *getInlinedAt() const { return getOperand(1); } >> }; >> >> Proposed assembly syntax: >> >> ; Not inlined. >> !7 = metadata !MDLineTable(line: 45, column: 7, scope: metadata !9) >> >> ; Inlined. >> !7 = metadata !MDLineTa...

...ntrinsic. >> >> https://reviews.llvm.org/D45078 > > In this revised design it is now possible to attach a DILabel to a BasicBlock. When the basic block is inlined it will be ambiguous to which function the DILabel belongs. For instructions, we store the inline information in the inlinedAt: field of its DILocation. In order to handle inlining for DILabels we have two options: > > 1. Also attach a DILocation to be associated with the label to carry the inline information, and teach the inliner to correctly update the DILocation on basic blocks during inlining. This would also...

...l double bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to double), %129 > > > > <badref> = fsub double -0.000000e+00, %153, !dbg !DILocation(line: 483, column: 29, scope: <0x6d73b40>, inlinedAt: !DILocation(line: 1032, column: 7, scope: <0x69a9230>) > > > > Step 2 (Applied fmul's SimplifyAssociativeOrCommutative policy. More specifically, "order operands such that they are listed from right (least complex) to left (most complex)" policy). > > > &gt...

...LineTable *getBase(MDLineTable *Inlined); unsigned getLine() const { return Line; } unsigned getColumn() const { return Column; } bool isInlined() const { return getNumOperands() == 2; } MDNode *getScope() const { return getOperand(0); } MDNode *getInlinedAt() const { return getOperand(1); } }; Proposed assembly syntax: ; Not inlined. !7 = metadata !MDLineTable(line: 45, column: 7, scope: metadata !9) ; Inlined. !7 = metadata !MDLineTable(line: 45, column: 7, scope: metadata !9,...

....org/D45078 > > > > > > In this revised design it is now possible to attach a DILabel to a > > BasicBlock. When the basic block is inlined it will be ambiguous to > > which function the DILabel belongs. For instructions, we store the > > inline information in the inlinedAt: field of its DILocation. In order > > to handle inlining for DILabels we have two options: > > > > > > 1. Also attach a DILocation to be associated with the label to carry > > the inline information, and teach the inliner to correctly update the > > DILocation...

On Fri, Mar 30, 2018 at 12:05 AM, Adrian Prantl <aprantl at apple.com> wrote: >> >> On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I would like to enhance LLVM debug info that supports setting >> breakpoint on labels in function. >> >> Generally, if users use GDB

On Tue, Mar 22, 2016 at 7:28 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > I have some ideas to allow the BitcodeReader to lazy-load debug info > metadata, and wanted to air this on llvm-dev before getting too deep > into the code. > > Motivation > ========== > > Based on some analysis Mehdi ran (ping him for details), there are three > (related)

...ericised the code in `LLParser` (and elsewhere) to sketch out how adding other `MDUser` subclasses will go. Perhaps I used the wrong axis, but we can adjust it as we go. Usage examples: !6 = metadata MDLocation(line: 43, column: 7, scope: !4) !7 = metadata MDLocation(scope: !5, line: 67, inlinedAt: !6) The fields can be listed in any order. The `scope:` field is required, but the others are optional (`line:` and `column:` default to `0`, `inlinedAt:` defaults to `null`). (Note that in the RFC I referred to this as an `MDLineTable`, but `MDLocation` is a better name. If/when this work sup...