search for: mdlocat

After splitting `Metadata` apart from `Value`, I'm finally back to the first step [1] of representing debug info more directly in IR [2]: `MDLocation`. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078173.html "First-class debug info IR: MDLocation" [2]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html "Less memory and greater maintainability for debug info IR" I've a...

I suspect it would actually be *better* if I got all this in before the branch, since it'll make cherry-picking testcases easier. However, these patches themselves (and I suspect a few more prep commits) don't actually move `MDLocation` into place -- it's not until then that all the testcase updates have to happen. I'm not convinced that (monster) commit will land by tomorrow :(. > On 2015-Jan-13, at 10:34, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > > Okay, we can deal with it, ju...

...gt; --paulr > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Duncan P. N. Exon Smith > *Sent:* Monday, January 12, 2015 8:30 PM > *To:* LLVM Developers Mailing List > *Subject:* [LLVMdev] [RFC] First-class debug info IR: MDLocation (redux) > > > > After splitting `Metadata` apart from `Value`, I'm finally back to the > first step [1] of representing debug info more directly in IR [2]: > `MDLocation`. > > [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078173.html > "...

....com> wrote: > > >> On Jan 14, 2015, at 11:12 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote: >> One small request: Omitting the column field from MDLocation if it is 0 is fine, because it won’t make it into the line table. Omitting the line if it is 0 is not, because it gives the wrong impression that the line is being ignored, which is not the case. Line 0 will be emitted in the line table and has special semantics (Line 0 in DWARF may be used to m...

...it'll make cherry-picking testcases easier. > > Excellent point, go for it. I missed the branch deadline, but I merged it in as of r226095. > --paulr > >> >> However, these patches themselves (and I suspect a few more prep >> commits) don't actually move `MDLocation` into place -- it's not >> until then that all the testcase updates have to happen. I'm not >> convinced that (monster) commit will land by tomorrow :(. >> >>> On 2015-Jan-13, at 10:34, Robinson, Paul >> <Paul_Robinson at playstation.sony.com> wro...

On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote: > One small request: Omitting the column field from MDLocation if it is 0 is > fine, because it won’t make it into the line table. Omitting the line if it > is 0 is not, because it gives the wrong impression that the line is being > ignored, which is not the case. Line 0 will be emitted in the line table > and has special semantics (Line 0 in DW...

I've attached a preliminary patch for `MDLocation` as a follow-up to the RFC [1] last week. It's not commit-ready -- in particular, it squashes a bunch of commits together and doesn't pass `make check` -- but I think it's close enough to indicate the direction and work toward consensus. [1]: http://lists.cs.uiuc.edu/pipermail/llvm...

I just finished the work for PR21433. I think it's relatively low risk, but it does change assembly output. Should I commit this before or after the (imminent) 3.6 branch? (I would have committed it tonight, but the buildbots are fairly red, and I prefer to break out-of-tree code in the morning anyway.) -------------- next part -------------- A non-text attachment was scrubbed... Name:

> On 2014-Oct-27, at 09:33, David Blaikie <dblaikie at gmail.com> wrote: > >> > Would it be possible to omit the names of unreferenced nested metadata? (if you have a bunch of member functions in a class, but don't need to refer to them elsewhere (eg: those member functions aren't defined in this translation unit)) - that'd help readability/writeability, but

On 15 January 2015 at 13:35, Renato Golin <renato.golin at linaro.org> wrote: > AArch64 tested and uploaded. ARMv7 in progress. Hi Hans, ARMv7 is giving me a bit of a headache... I've tried building on two different machines and I get the same error... Phase 2 completes successfully, but while building Phase 3, I get the error on *every* file: 1.

> On 2015-Jan-15, at 09:35, Hans Wennborg <hans at chromium.org> wrote: > > On Wed, Jan 14, 2015 at 8:26 PM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2015 Jan 13, at 11:13, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >>> >>>> I suspect it would actually be *better* if I got all this

> On 2014-Oct-24, at 16:37, David Blaikie <dblaikie at gmail.com> wrote: > >> Notice that only the links to parents (i.e., `context:`) are explicit >> here -- backlinks are implied. For example, !7 and !8 point to !6, but >> not the reverse. > > This may be a problem - the difference between nodes in a structure/class_type's member list, and those that

...tween the branch point and the rc1 tag. They were: > > r226023 InstCombine: Don't take A-B<0 into A<B if A-B has other uses > r226029 IR: Fix a use-after-free in RAUW > r226044 IR: Drop metadata references more aggressively during teardown > r226046 IR: Always print MDLocation line > r226049 IR: Move MDLocation into place (clang testcases) > r226048 IR: Move MDLocation into place > r226058 IR: Fix comment spelling, NFC None of that seems to be the culprit. I think the real problem here is that the release scripts are building with autoconf and our buil...

...ull, null} ; [ DW_TAG_base_type ] [int] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed] -!10 = !{!"0x101\00p\0016777217\000", !5, !6, !9} ; [ DW_TAG_arg_variable ] [p] [line 1] +!10 = !{!"0x101\00p\001\001\000", !5, !6, !9} ; [ DW_TAG_arg_variable ] [p] [line 1] !11 = !MDLocation(line: 1, scope: !5) -!12 = !{!"0x100\00r\002\000", !13, !6, !9} ; [ DW_TAG_auto_variable ] [r] [line 2] +!12 = !{!"0x100\00r\002\000\000", !13, !6, !9} ; [ DW_TAG_auto_variable ] [r] [line 2] Before I spend cycles updating the test cases, I wanted get a 'go ahead' fr...

> On 2014-Oct-27, at 00:58, Chandler Carruth <chandlerc at google.com> wrote: > > I haven't been able to follow all of the thread that got us here but your patch below has distilled the result enough for me to at least ask questions. Always takes a patch to draw people in :). > I'm sorry of some of the justification is buried in the thread and I'm just making you

...32, align 32, offset 0, enc >> DW_ATE_signed] >> -!10 = !{!"0x101\00p\0016777217\000", !5, !6, !9} ; [ >> DW_TAG_arg_variable ] [p] [line 1] >> +!10 = !{!"0x101\00p\001\001\000", !5, !6, !9} ; [ DW_TAG_arg_variable >> ] [p] [line 1] >> !11 = !MDLocation(line: 1, scope: !5) >> -!12 = !{!"0x100\00r\002\000", !13, !6, !9} ; [ DW_TAG_auto_variable ] >> [r] [line 2] >> +!12 = !{!"0x100\00r\002\000\000", !13, !6, !9} ; [ >> DW_TAG_auto_variable ] [r] [line 2] >> >> Before I spend cycles updating...

On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > >> > >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> > >> > >> On Tue, Jan 13, 2015

I am trying to locate instructions in an LLVM Pass by line and column number (reported by an third-party tool) to instrument them. To achieve this, I am compiling my source files with `clang -g -O0 -emit-llvm` and looking for the information in the metadata using this code: const DebugLoc &location = instruction->getDebugLoc(); // location.getLine() // location.getCol()

...[1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/242667.html "r221167 - IR: MDNode => Value: Instruction::getAllMetadataOtherThanDebugLoc()" [2]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078581.html "Re: First-class debug info IR: MDLocation" -------------- next part -------------- A non-text attachment was scrubbed... Name: metadata-v2.patch Type: application/octet-stream Size: 31022 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141109/4d4fffcf/attachment.obj>