[llvm-dev] CloneFunctionInto produces invalid debug info

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 19 15:00:09 PDT 2017


- old Keno
+current Keno
> On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote:
> 
> In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment.
> 
>> (lldb) p OldFunc->dump()
>> 
>> ; Function Attrs: nounwind optsize
>> define internal void @f_1.extracted_region(i32, i32*, %struct.t_c*, %struct.t_d*) #0 {
>> if.end12.extracted_entry:
>>  %and14 = and i32 %0, 2, !dbg !89
>>  %tobool15 = icmp eq i32 %and14, 0, !dbg !89
>>  br i1 %tobool15, label %exit, label %if.then16, !dbg !185
>> 
>> if.then16:                                        ; preds = %if.end12.extracted_entry
>>  %4 = load i32, i32* %1, align 4, !dbg !186
>>  %or18 = or i32 %4, 2, !dbg !186
>>  store i32 %or18, i32* %1, align 4, !dbg !186
>>  %pps = getelementptr inbounds %struct.t_c, %struct.t_c* %2, i32 0, i32 4, !dbg !188
>>  %5 = load i32, i32* %pps, align 8, !dbg !188
>>  %to20 = getelementptr inbounds %struct.t_d, %struct.t_d* %3, i32 0, i32 2, i32 0, i32 0, !dbg !189
>>  store i32 %5, i32* %to20, align 4, !dbg !190
>>  %pp = getelementptr inbounds %struct.t_c, %struct.t_c* %2, i32 0, i32 2, !dbg !191
>>  %6 = load i8, i8* %pp, align 8, !dbg !191
>>  %us = getelementptr inbounds %struct.t_d, %struct.t_d* %3, i32 0, i32 2, i32 0, i32 1, !dbg !192
>>  store i8 %6, i8* %us, align 4, !dbg !193
>>  br label %exit, !dbg !194
>> 
>> exit:                                             ; preds = %if.then16, %if.end12.extracted_entry
>>  ret void
>> }
> 
> 
> Apparently the Verifier currently doesn't reject this, but this is not valid. If you want the debug info to survive you should create a new DISubprogram for the .extracted_region function and reparent the debug locations of the instructions into it, or you should strip all debug info from the function and its instructions.
> Otherwise (as in the example) CloneFunction will not properly seed the metadata value mapper because the DISubprogram is missing. This then causes a deep copy of the debug locations all the way up to the DICompileUnit to be made.
> 
> -- adrian
> 
>> On Jun 16, 2017, at 2:00 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> The if you are cloning into the same LLVM module the CU should not cloned. If don't mind sharing your code, I can try to help diagnose why the CU gets cloned... just send me a patch that applies to trunk and instructions.
>> 
>> -- adrian
>> 
>>> On Jun 16, 2017, at 1:54 PM, Sergei Larin <slarin at codeaurora.org> wrote:
>>> 
>>> Sorry… It takes a pass that was not accepted for upstreaming…. It uses CloneFunctionInto with module level flag on. In the input IR there is a strangely formed (but correct) debug info MD that causes duplication of existing DICompileUnit during cloning, but llvm.dbg.cu is not updated. I got around by a quick cleanup pass that detects the situation and simply adds them in… Something like this:
>>> 
>>> auto *CUs = F->getParent()->getNamedMetadata("llvm.dbg.cu");
>>> if (!CUs)
>>>   return;
>>> 
>>> SmallPtrSet<Metadata *, 2> Listed;
>>> Listed.insert(CUs->op_begin(), CUs->op_end());
>>> 
>>> for (auto *CU : CUVisited)
>>>   if (!Listed.count(CU)) {
>>>     auto *Op = dyn_cast<MDNode>(CU);
>>>     CUs->addOperand(Op);  <<<<<<<<<<<<<<<<<<<<<<<
>>>   }
>>> 
>>> Sorry, I realize this is not much help.
>>> 
>>> Sergei
>>> 
>>> From: aprantl at apple.com [mailto:aprantl at apple.com] 
>>> Sent: Thursday, June 15, 2017 5:25 PM
>>> To: Sergei Larin <slarin at codeaurora.org>
>>> Cc: Keno Fischer <keno at juliacomputing.com>; llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] CloneFunctionInto produces invalid debug info
>>> 
>>> Can you send me a patch with instructions to reproduce? I can take a look.
>>> 
>>> -- adrian
>>>> On Jun 15, 2017, at 2:23 PM, Sergei Larin <slarin at codeaurora.org> wrote:
>>>> 
>>>> Yes, it does for us. My tree is couple days off the tip, and I see it there.
>>>> 
>>>> Sergei
>>>> 
>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Keno Fischer via llvm-dev
>>>> Sent: Thursday, June 15, 2017 1:25 PM
>>>> To: Adrian Prantl <aprantl at apple.com>
>>>> Cc: llvm-dev <llvm-dev at lists.llvm.org>
>>>> Subject: Re: [llvm-dev] CloneFunctionInto produces invalid debug info
>>>> 
>>>> This all looks very similar to a bug in the cloning stuff I fixed recently, so would be indeed good to know if this is still happening on master.
>>>> 
>>>> On Thu, Jun 15, 2017 at 2:23 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>> If you are doing this work based off LLVM trunk, could you send me your patch to reproduce the problem?
>>>>> 
>>>>> -- adrian
>>>>>> On Jun 15, 2017, at 8:31 AM, Matthias Bernad via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> We are currently working on a science project and implemented a FunctionPass that clones a function (more precisely a constructor of a struct/class) and adds a parameter.
>>>>>> 
>>>>>> First, we create a new function with a new function type, which includes the newly added parameter:
>>>>>> 
>>>>>>> Function *NF = Function::Create(NewFTy, F.getLinkage(), F.getName() + "Cloned", F.getParent());
>>>>>> 
>>>>>> and after setting up the ValueToValueMapTy, we use the CloneFunctionInto method to clone the function body
>>>>>> 
>>>>>>> CloneFunctionInto(NF, &F, Map, true, Returns, "Cloned");
>>>>>> 
>>>>>> The code seems to work as intended, but when we try to emit debug symbols (clang -g flag) the pass fails with following message:
>>>>>> 
>>>>>>> "All DICompileUnits must be listed in llvm.dbg.cu"
>>>>>> 
>>>>>> Nevertheless, we can dump the Module and therefore can print out the annotated IR.
>>>>>> 
>>>>>> This is what the function to be cloned looks like:
>>>>>> 
>>>>>>> ; Function Attrs: noinline nounwind uwtable
>>>>>>> define linkonce_odr void @_ZN12MyFunnyClassC2Ev(%struct.MyFunnyClass* %this) unnamed_addr #4 comdat align 2 !dbg !46 {
>>>>>>> entry:
>>>>>>> %this.addr = alloca %struct.MyFunnyClass*, align 8
>>>>>>> store %struct.MyFunnyClass* %this, %struct.MyFunnyClass** %this.addr, align 8
>>>>>>> call void @llvm.dbg.declare(metadata %struct.MyFunnyClass** %this.addr, metadata !49, metadata !31), !dbg !50
>>>>>>> ... rest of function code
>>>>>>> }
>>>>>>> 
>>>>>>> !46 = distinct !DISubprogram(name: "MyFunnyClass", linkageName: "_ZN12MyFunnyClassC2Ev", scope: !15, file: !1, line: 1, type: !25, isLocal: false, isDefinition: true, scopeLine: 1, flags: DIFlagArtificial | DIFlagPrototyped, isOptimized: false, unit: !0, declaration: !47, variables: !2)
>>>>>> 
>>>>>> and the cloned function:
>>>>>> 
>>>>>>> ; Function Attrs: noinline nounwind uwtable
>>>>>>> define linkonce_odr void @_ZN12MyFunnyClassC2EvCloned(%struct.MyFunnyClass* %this, { [6 x i8*] }* %newparam) unnamed_addr #4 align 2 !dbg !73 {
>>>>>>> entry:
>>>>>>> %this.addr = alloca %struct.MyFunnyClass*, align 8
>>>>>>> store %struct.MyFunnyClass* %this, %struct.MyFunnyClass** %this.addr, align 8
>>>>>>> call void @llvm.dbg.declare(metadata %struct.MyFunnyClass** %this.addr, metadata !89, metadata !31), !dbg !91
>>>>>>> ... rest of function code
>>>>>>> }
>>>>>>> 
>>>>>>> !73 = distinct !DISubprogram(name: "MyFunnyClass", linkageName: "_ZN12MyFunnyClassC2Ev", scope: !74, file: !1, line: 1, type: !81, isLocal: false, isDefinition: true, scopeLine: 1, flags: DIFlagArtificial | DIFlagPrototyped, isOptimized: false, unit: !87, declaration: !88, variables: !2)
>>>>>>> 
>>>>>> So the cloned function gets annotated with debug symbols as expected. We noticed that the linkageName of the cloned function is the same as the original one's. Could that cause the error mentioned above? If so, how can we fix that error?
>>>>>> 
>>>>>> Best regards and thanks in advance,
>>>>>> Matthias
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 



More information about the llvm-dev mailing list