search for: modulelevelchanges

...mall pass [1]. >> >> If I run this pass with opt, I get the expected result (i.e. a valid program that calls main twice). If I run the pass during LTO, ld seg faults. Here is a pastebin of when ld seg faults in lldb [2]. >> >> If I set the third parameter of CloneFunction (ModuleLevelChanges) to false, then then compilation will complete -- but I lose debugging information in the cloned function. I really want to preserve the debug info. >> >> Any idea what is wrong? Is this a bug? Usually when I screw up the module the verifier catches the problem. This is getting to I...

...blem so that it occurs in this small pass [1]. If I run this pass with opt, I get the expected result (i.e. a valid program that calls main twice). If I run the pass during LTO, ld seg faults. Here is a pastebin of when ld seg faults in lldb [2]. If I set the third parameter of CloneFunction (ModuleLevelChanges) to false, then then compilation will complete -- but I lose debugging information in the cloned function. I really want to preserve the debug info. Any idea what is wrong? Is this a bug? Usually when I screw up the module the verifier catches the problem. This is getting to I think CodeG...

...MESSAGE----- Hash: SHA1 Hi all, unless I overlook something, the second version of CloneFunction() (from http://llvm.org/doxygen/Cloning_8h_source.html): 00114 Function *CloneFunction(const Function *F, 00115 ValueToValueMapTy &VMap, 00116 bool ModuleLevelChanges, 00117 ClonedCodeInfo *CodeInfo = 0); 00118 00119 /// CloneFunction - Version of the function that doesn't need the VMap. 00120 /// 00121 inline Function *CloneFunction(const Function *F, ClonedCodeInfo *CodeInfo = 0){ 00122 ValueToValueMapTy VMap; 00123 return Clone...

y > On Feb 11, 2016, at 8:00 AM, Scott A. Carr <carr27 at purdue.edu> wrote: > > Hello again, > > I've narrowed down my issue to a small test case. The core of the issue is that CloneFunction (with ModuleLevelChanges=true) on a function that has had other functions inlined into it generates orphan debug info metadata nodes. Then when this module is emitted, DwarfDebug crashes. > > The C program is here [1]. Note that the inliner should inline add into main. > > If compile that C program with &qu...

...34-0410-b5e6-96231b3b80d8 we will have stale DISubprogram because RemapInstruction called from CloneFunctionInto() (here) // Loop over all instructions, fixing each one as we find it... for (Instruction &II : *BB) { RemapInstruction(&II, VMap, ModuleLevelChanges ? RF_None : RF_NoModuleLevelChanges, TypeMapper, Materializer); } …will actually skip over “metadata i8* null” operands of “call void @llvm.dbg.value” and will not update correspondent debug records… Now the first time verifier takes a look at this, we got an assert...

I will start from afar… When a dead function argument is removed, should we keep around the debug info for it? I have the following case: define internal fastcc void @foo(i8* %aa, i8* %reg, i8* %field, i32 %bb, ...) unnamed_addr #3 !dbg !28 { entry: call void @llvm.dbg.value(metabb i8* %aa, i64 0, metabb !34, metabb !47), !dbg !57 call void @llvm.dbg.value(metabb i8* %reg, i64 0,