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.
> >>
> >...
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...