similar to: [LLVMdev] Checking validity of metadata in an .ll file

On Dec 16, 2011, at 8:05 AM, Seb wrote: > Hi all, > > I was wondering if there is a way to check that metadata emitted in an LLVM file are corrects with respect to debug informations. Right now there is no such check. In fact, 'llc' is trained to silently ignore malformed debug information, because 'opt' is not held reliable to maintain debug info. That said, it would

Hi Devang, Thanks for the answer, I eventually found that in DW_TAG_compile_unit metadata, if field for 'main' compile unit is set to false then no debug info is generated. Can someone explain what is the meaning of this field ? You wrote: "Right now there is no such check. In fact, 'llc' is trained to silently ignore malformed debug information, because 'opt' is

Hi Devang, Not only "vtable ptr" is a problem, for this field it seems that CLANG emits a NULL metadata node which is translated into 'i32 0'. The other problem is for 'isArtificial' field with is described as being of type i1 and CLANG emits i32. Looking at sources, it seems that it should be a i32 flag field. Hope this helps, Best Regards Seb 2011/12/15 Devang

Hi all, In LLVM documentation about source level debugging (http://www.llvm.org/releases/2.9/docs/SourceLevelDebugging.html) Subprogram descriptor is defined as: !2 = metadata !{ i32, ;; Tag = 46 + LLVMDebugVersion <http://www.llvm.org/releases/2.9/docs/SourceLevelDebugging.html#LLVMDebugVersion> ;; (DW_TAG_subprogram) i32, ;; Unused field. metadata, ;;

On Dec 15, 2011, at 2:32 AM, Seb wrote: > Hi all, > > In LLVM documentation about source level debugging (http://www.llvm.org/releases/2.9/docs/SourceLevelDebugging.html) > > > Subprogram descriptor is defined as: > > !2 = metadata !{ > i32, ;; Tag = 46 + LLVMDebugVersion > ;; (DW_TAG_subprogram) > > i32, ;; Unused field. >

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

Hi all, I'm using my own front-end to generate following code .ll file targeting x86 32-bit: ; ModuleID = 'check.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @.str581 = internal constant [52 x i8] c"---- test number %d

Hi all, Anyone have ideas/info on this topic ? Thanks Seb 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting > x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout = >

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

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

When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR. (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list,

On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: > When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR.  (e.g. in the MD for DW_TAG_compile_unit's

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

Hi James, I fully agree with you and understand your statement about -O2. Now some questions for you: Did you try to reproduce experiments described in my previous e-mail ? Did you look at debug informations generated for 'n' parameter on x86 32-bit & x86 64-bit ? I'm working on my own front-end for LLVM and I had difficulties with debug information when they are related to x86

Hi all, Can someone give me advice on what should be a good definition of target datalayout for an ARM cortex-A9 + neon target and x86 32-bit ? Shall I use a different definition for a cortex-A9 without neon ? Thanks for your advices Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

I tried bu clang seems to support only target on which it has been compiled. If I use: with clang -S -emit-llvm t.c -o t.ll I've got following file for t.ll ; ModuleID = 't.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple =

On Wed, Mar 7, 2012 at 6:50 AM, Seb <babslachem at gmail.com> wrote: > Hi James, > > I fully agree with you and understand your statement about -O2. > > Now some questions for you: > Did you try to reproduce experiments described in my previous e-mail ? > Did you look at debug informations generated for 'n' parameter on x86 32-bit > & x86 64-bit ? >