similar to: RFC: DI: Stop preserving types from dead functions

> 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

> On May 6, 2016, at 4:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On May 6, 2016, at 3:53 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >>> >>> 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

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i

On Feb 11, 2012, at 7:51 AM, Yuri Pankov <yuri.pankov at gmail.com> wrote: > Hi, > > ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: > die 141: base type without name). Is it intended behavior? Not that I know of, please file a bug. Thanks! -eric

> 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

Thanks! Unfortunately this doesn't seem to cause it, because when I fix it to match the other files (and pretty much how clang emits it:) !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression()) !1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName: "f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID", scope: !2, file: !3, type: !622, isLocal:

Hi Paul, Thanks for your response. Let me actually post more details visualizing my case. Assuming that can help. so the IR before the opt tool is running is: ; Function Attrs: nounwind define i16 @main() #0 !dbg !13 { entry: %retval = alloca i16, align 1 ... } ; Function Attrs: inlinehint nounwind define internal void @delay(i16 %d) #4 !dbg !69 { entry: %d.addr = alloca i16,

On Mon, Jul 30, 2018 at 6:52 AM <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Xin > > Tong via llvm-dev > > Sent: Friday, July 27, 2018 9:33 PM > > To: llvm-dev > > Subject: [llvm-dev] ThinLTO Bug ? > > > > Hi > > > > I

Yep, it's once again variable and it's type using different scopes. Is there any strong reason why you set scope for global DIDerivedType? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 18:22 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Thanks! Unfortunately this

Hi Arsen, we are beyond what I understand about how metadata operates. Maybe Adrian or David knows. --paulr From: Arsen Hakobyan [mailto:hakobyan.ars at gmail.com] Sent: Friday, January 12, 2018 12:16 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org; David Blaikie Subject: Re: [llvm-dev] StripDeadDebugInfo for static inline functions. Just one update: the function causing the segmentation

Hi all, I would like to understand the strip-dead-debug-info transformation. In my test case there is a static inline function with two local variables. It appears that the function is already inlined before strip-dead-debug-info starts its work. As a result the DICompileUnit is cleaned and its subprograms list has no reference to the DISubprogram for the inlined function, but as there is

Op 21-3-2018 om 10:28 schreef Evgeny Leviant: > It looks the problem lies in how your compiler generates debug info. LLVM doesn't > expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: > > DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { > - if (!Context || isa<DIFile>(Context)) > + if (!Context ||

Just one update: the function causing the segmentation fault is the following: 359 void DwarfDebug::constructAbstractSubprogramScopeDIE(LexicalScope *Scope) { 360 assert(Scope && Scope->getScopeNode()); 361 assert(Scope->isAbstractScope()); 362 assert(!Scope->getInlinedAt()); 363 364 const MDNode *SP = Scope->getScopeNode(); 365 366

I'm not as familiar with all the ins and outs of metadata as maybe I should be, but ultimately the inlined function should have a DWARF description contained within the description of the caller (which is why you're seeing the call to constructAbstractSubprogramScopeDIE). That suggests that the DISubprogram for the inlined function ought to remain, and its scope should be the

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

Ok, I've done a bit more investigation. I found the module which declares broken DIE (e54b3dc8c0536e29a65f8548b5ae7958-Global.o) and here is what I found there: !2 = !DIFile(filename: "island.windows.elements", ... ... !4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !5, ... !5 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global",

Thanks Paul, Hi Adrian and David I would really appreciate any comments, thoughts assumptions. If additional information is needed please let me know. Regards, Arsen On Sat, Jan 13, 2018 at 2:54 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > Hi Arsen, we are beyond what I understand about how metadata operates. > Maybe Adrian or David knows. > > --paulr > >

Hi I have encountered a module verification failure when running 2 files with thin-lto (I hit this bug in the link step in LTO on a really large program and I reduced to this test case). ~/llvmfb/build-debug/bin/llvm-lto2 run -o c a.o b.o -r a.o,c,px -r b.o,a,px -r b.o,b,px -r a.o,gv -r b.o,gv Called function is not the same type as the call! %2 = call i1 bitcast (i1 (%struct.TA*)* @b to i1

+ Adrian + David Hi Arsen, This sounds like a bug to me. Have you tried reproducing it on trunk? For instance, I see that the relation between DICompileUnit and DISubprogram was changed in the meantime (https://reviews.llvm.org/D19034 <https://reviews.llvm.org/D19034>). If this no longer occurs on master you could bisect the compiler to find the commit(s) that fix this and consider

> On 2016-Mar-23, at 07:17, Teresa Johnson <tejohnson at google.com> wrote: > > > > 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 >