similar to: [LLVMdev] need pointers navigating through metadata in llvm :-)

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Dear all, I have the following source code: long f(long x, long y) { long u; u = x+y; return u; }; After clang (with debug option set) and llvm opt using mem2reg, I get the following .ll file *************************************************************************** ; ModuleID = '<stdin>' target datalayout =

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

> On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions were

On Wed, Jul 14, 2010 at 3:03 PM, Arvind Sudarsanam <arvind.sudarsanam at aggiemail.usu.edu> wrote: > Dear all, > > I have the following source code: > > long f(long x, long y) > { >        long u; > >   u = x+y; >   return u; > }; > > After clang (with debug option set) and llvm opt using mem2reg, I get > the following .ll file >

Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

Trying to wrap my brain around this, so a few questions below. =) On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> wrote: > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have already been made to DISubprogram. > > To reduce duplicate

On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: > Trying to wrap my brain around this, so a few questions below. =) > Sure thing - sorry, did assume a bit too much arcane context here. > > On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > Branching off from a discussion of improvements to

Eli, Thanks very much for your reply. That's what I want to know. It works for this example. But I usually have to deal with the optimized bytecode with "-O". See the example: ************** C source ************** int h (int j, int i) { int tmp; tmp = j+i+2; return tmp; } +++++++++++++++++++++++++++++++++++++ .ll file: ; ModuleID = 'simplecase.c' target

A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). Firstly, why *should* DISubprogram definitions be distinct? There were two reasons this was valuable (this was from before there was a cu: link). - It helped to fix long-standing bugs in the IRLinker, where uniqued-DISubprograms in different compile

On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: > >> Trying to wrap my brain around this, so a few questions below. =) >> > > Sure thing - sorry, did assume a bit too much arcane context here. > > >> >> On Thu, Dec

On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > A few disjoint thoughts; sorry they're so delayed (I skimmed the responses > below, and I think these are still relevant/not covered elsewhere). > > Firstly, why *should* DISubprogram definitions be distinct? There were > two reasons this was valuable (this was from before there

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

Hi, I want to know the variable mapping between the source and llvm bytecode. It seems that current llvm debugging information cannot provide this mapping directly. Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: tmp<--->%4. But current llvm's debugging information can only provide that the instruction "%4 = add nsw i32 %3, 2" is at line 3 in

> On Dec 23, 2016, at 18:36, David Blaikie <dblaikie at gmail.com> wrote: > > > >> On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). >> >> Firstly, why

On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> wrote: On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: Trying to wrap my brain around this, so a few questions below. =) Sure thing - sorry, did assume a bit too much arcane context here.

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: >

Hi, I want to get the mapping between C source's variables and bytecode variables. It seems that llvm doesn't provide this mapping, so I think a walk-around method is to get the instruction's mapping. I have to use llvm-gcc, not clang. Any advice? Thanks. Best, Kecheng 2010-05-13 From: Eli Friedman Date: 2010-05-13 15:38:36 To: Kecheng Cc: llvmdev Subject: Re: [LLVMdev] How