search for: pr17892

Displaying 7 results from an estimated 7 matches for "pr17892".

Did you mean: pr17891
2014 Oct 16
2
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
...> >> In r219010, I merged integer and string fields into a single header >> field. By reducing the number of metadata operands used in debug info, >> this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling >> of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and >> I've concluded that they will be insufficient. >> >> Instead, I'd like to implement a more aggressive plan, which as a >> side-effect cleans up the much "loved" debug info IR assembly syntax. >> >> At a high-level, the ide...
2014 Oct 13
9
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan, which as a side-effect cleans up the much "loved" debug info IR assembly syntax. At a high-level, the idea is to create distinct subclasses of `Value` for ea...
2014 Oct 15
3
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
...n r219010, I merged integer and string fields into a single header > >> field. By reducing the number of metadata operands used in debug info, > >> this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling > >> of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and > >> I've concluded that they will be insufficient. > >> > >> Instead, I'd like to implement a more aggressive plan, which as a > >> side-effect cleans up the much "loved" debug info IR assembly syntax. > >> > &gt...
2013 Nov 12
0
[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)
On Mon, Nov 11, 2013 at 11:29 PM, Chris Lattner <clattner at apple.com> wrote: > Hi Manman (and llvmdev), > > I filed these two bugs to track the ideas that I was cooking: > > http://llvm.org/bugs/show_bug.cgi?id=17891 > http://llvm.org/bugs/show_bug.cgi?id=17892 > > TL;DR: I'm saying we should go from: > > !14 = metadata !{i32 786445, metadata !1,
2014 Oct 14
2
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
...pple.com> wrote: > In r219010, I merged integer and string fields into a single header > field. By reducing the number of metadata operands used in debug info, > this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling > of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and > I've concluded that they will be insufficient. > > Instead, I'd like to implement a more aggressive plan, which as a > side-effect cleans up the much "loved" debug info IR assembly syntax. > > At a high-level, the idea is to create distinct...
2013 Nov 12
3
[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)
Hi Manman (and llvmdev), I filed these two bugs to track the ideas that I was cooking: http://llvm.org/bugs/show_bug.cgi?id=17891 http://llvm.org/bugs/show_bug.cgi?id=17892 TL;DR: I'm saying we should go from: !14 = metadata !{i32 786445, metadata !1, metadata !10, metadata !"y", i32 3, i64 32, i64 32, i64 32, i32 0, metadata !13} to: !14 = metadata
2013 Nov 13
3
[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)
...a few tweaks. > > First, there are two things going on here: removing an indirection through a referenced metadata node and flattening N values into a string inclusion. Removing the indirection seems obvious strict goodness, my comments are about the second part. David pointed out that the PR17892 is a microoptimization that may not even be worthwhile. I think that the flattening into a string is the important part. > I'm moderately opposed to just encoding these in a string format. I think we can do something substantially better both for space, time, and readability. Fundamentally...