similar to: RFC: Up front type information generation in clang and llvm

On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sharing this. Mostly seems like a reasonable plan to me. A few > comments below. > > Thanks Peter! > On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi All, >> >> This is something that's been

On Tue, Mar 29, 2016 at 8:11 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Mar 29, 2016 at 7:43 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> >> >> On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> Thanks for sharing this. Mostly seems like a reasonable plan to me.

On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Skipping a serialization and doing something clever about LTO uniquing > sounds awesome. I'm guessing you achieve this by extracting types out of > DI metadata and packaging them as lumps-o-DWARF that the back-end can then > paste together? Reading between the lines a bit

On Tue, Mar 29, 2016 at 7:43 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sharing this. Mostly seems like a reasonable plan to me. A few >> comments below. >> >> > Thanks Peter! > > >> On Tue, Mar 29, 2016 at 6:00 PM, Eric

How will this affect other languages that generate debug info - not that you should care about those, I'm just curious - my Pascal compiler does not generate clang-style AST, and does not use clang at all. I currently have code that in uses DIBuilder directly... -- Mats On 30 March 2016 at 04:15, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue,

> On Mar 29, 2016, at 11:35 PM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > How will this affect other languages that generate debug info - not that you should care about those, I'm just curious - my Pascal compiler does not generate clang-style AST, and does not use clang at all. I currently have code that in uses DIBuilder directly... I don’t think that

I don't agree in general here because of: a) maintainability - there isn't a one true path through things and now is scattering more windows knowledge through debug info and lto b) higher bar for implementing similar dwarf functionality - there's nothing here that makes it at any point better for our general debug info support. Incrementally updating to an intermediate step is much

Thanks for sharing this. Mostly seems like a reasonable plan to me. A few comments below. On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > This is something that's been talked about for some time and it's probably > time to propose it. > > The "We" in this document is everyone on the cc line

On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > >> Skipping a serialization and doing something clever about LTO uniquing >> sounds awesome. I'm guessing you achieve this by extracting types out of

Hi Mehdi, I understand the reasoning for supporting this proposal independently from CodeView support. However, I do not think that it is needed for supporting CodeView. When I say that my suggestion is more clean, I was pointing to CodeView support, assuming the changes in LLVM IR/Clang FE indicated in this proposal. Also, it is not that clear from the proposal what will be shared (generic)

Skipping a serialization and doing something clever about LTO uniquing sounds awesome. I'm guessing you achieve this by extracting types out of DI metadata and packaging them as lumps-o-DWARF that the back-end can then paste together? Reading between the lines a bit here. Can you share data about how much "pure" types dominate the size of debug info? Or at least the current

> On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul <Paul_Robinson at playstation.sony.com

On Mar 31, 2016 7:11 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: >> >> >> >> On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: >>> >>> Skipping a

The split between CodeView and DWARF will happen at the level of type information. So, DIVariable, DISubprogram, DILocation, DILocalScope, etc will all be shared, but records and composite types etc will not. On Thu, Mar 31, 2016 at 3:44 PM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi, > > I understand the reasoning for supporting this proposal

> On Mar 31, 2016, at 8:50 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev <cfe-dev at lists.llvm.org

Hi Eric, I'm coming back on this topic after discussing this offline quickly with Reid, and at length with Adrian, Duncan, and Fred. I may have to take back some of my words from my previous email, especially as it is not clear how and why what Reid is proposing to do is hurting a future path for Dwarf. Especially, if my understanding is correct, the key point that differentiate what Reid is

On Fri, Apr 15, 2016 at 9:50 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > Since I haven't heard any objections to the direction, I'm planning to > commit this (step 4) when I find some cycles; likely over the weekend. > > To make this more concrete (in case someone is silently concerned) I've > posted my WIP patches below. They apply cleanly to

On Fri, Apr 15, 2016 at 2:27 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Apr-15, at 10:27, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Fri, Apr 15, 2016 at 9:50 AM, Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > Since I haven't heard any objections to the direction,

I have no objections to any of this FWIW :) -eric On Tue, Mar 29, 2016 at 6:46 PM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > > > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> +pcc, who had some other

> On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: >> +pcc, who had some other ideas/patch out for improving memory usage of debug info >> +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about