similar to: Emitting output file information in Debug Info Metadata

> On Nov 13, 2018, at 1:07 PM, Reid Kleckner <rnk at google.com> wrote: > > Overall, I think we should do this. It's one of the most popular out of tree extensions that people make to LLVM and clang, and we want it for codeview anyway. Why isn't OPT_dwarf_debug_flags good enough for codeview? -- adrian > We currently don't emit a command line there. Other than

+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 changes to type emission So how does this relate, or not, to Peter's (pcc) work trying to reduce the DIE overhead during code gen? Are you folks chasing different memory bottlenecks? Are they both

> On 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 changes to type emission > > So how does this relate, or not, to Peter's (pcc) work trying to

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) compile-time bottlenecks we're seeing with `-flto=thin -g`: a) Reading the large number of Metadata bitcode records in the global

RFC: CodeView debug info emission in Clang/LLVM Overview On Windows, the de facto debug information format is CodeView, most commonly encountered in the form of a .pdb file. This is the format emitted by the Visual C++, C#, and VB.NET compilers, consumed by the Visual Studio debugger and the Windows debugger (WinDbg), and exposed for read-only access via the DIA SDK. The CodeView format has never

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

On Tue, Mar 22, 2016 at 9:48 PM, Duncan Exon Smith <dexonsmith at apple.com> wrote: > > On 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

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,

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honestly saying I only

>If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication. > >This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM. > >This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. >Though

I just wrote an IR Verifier check that catches the following situation: ; RUN: not llvm-as %s -disable-output 2>&1 | FileCheck %s define void @f1() !dbg !4 { unreachable } ; CHECK: DISubprogram attached to more than one function define void @f2() !dbg !4 { unreachable } !llvm.dbg.cu = !{!1} !1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2) !2

On Fri, Apr 15, 2016 at 4:04 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Apr-15, at 14:53, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > >> 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

On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi David, > > The way I imagined that we might want to extend the MCStreamer API (this > was motivated by DIEData) is by allowing clients to move bytes and fixups > into the MC layer. > > This is the sort of API that I was imagining: > > void

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 changes to type emission > > So I discussed this with Adrian and Mehdi at the social last

On Mon, Feb 29, 2016 at 03:47:49PM -0800, David Blaikie wrote: > On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > Hi David, > > > > The way I imagined that we might want to extend the MCStreamer API (this > > was motivated by DIEData) is by allowing clients to move bytes and fixups > > into the MC layer. >

Hi David, The way I imagined that we might want to extend the MCStreamer API (this was motivated by DIEData) is by allowing clients to move bytes and fixups into the MC layer. This is the sort of API that I was imagining: void MoveAndEmitFragment(SmallVectorImpl<char> &&Data, SmallVectorImpl<MCFixup> &&Fixups); Note that this mirrors the

> >> On 2016-Apr-15, at 17:12, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Fri, Apr 15, 2016 at 4:04 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> > On 2016-Apr-15, at 14:53, David Blaikie <dblaikie at gmail.com> wrote: >> > >> > >> > >> >> On Fri, Apr

> On May 6, 2016, at 3:17 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On May 6, 2016, at 1:17 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge, which should hopefully clear the way for removing the llvm.dbg.cu named metadata node. > > Not to spoil all

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)

> On May 6, 2016, at 3:48 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 6, 2016, at 3:40 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >>> On May 6, 2016, at 3:17 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>> On May 6, 2016, at 1:17 PM, Peter