<div dir="ltr">Ah, sure - we can't/shouldn't remove any inline scope information (if it's unambiguous - if we hoisted from two different function calls we should probably drop the inlining scope information in the same way that we drop the ambiguous locations, unfortunately), but block scopes may or may not be helpful to preserve. I'm not sure what the right answer is there.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 14, 2017 at 10:44 AM Taewook Oh via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">twoh added inline comments.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: lib/IR/Instruction.cpp:664-668<br class="gmail_msg">
+ if (Loc && isa<CallInst>(this)) {<br class="gmail_msg">
+ DbgLoc = DILocation::get(Loc->getContext(), 0, 0, Loc->getScope(),<br class="gmail_msg">
+ Loc->getInlinedAt());<br class="gmail_msg">
+ return;<br class="gmail_msg">
+ }<br class="gmail_msg">
----------------<br class="gmail_msg">
dblaikie wrote:<br class="gmail_msg">
> I'm not sure we can get the scope right, though - since we're potentially moving this location across scopes. It's going to be jumpy/create a difficult range in the scope no matter what, really...<br class="gmail_msg">
><br class="gmail_msg">
> Any ideas? Take the scope from a nearby location at the destination, if possible? (doesn't really reflect reality, but nothing will - this would at least mean a chance of not punching holes in/making islands in scopes that would necessitate a DW_AT_ranges/more verbose description/etc)<br class="gmail_msg">
It would be hard to get the precise scope anyway, but I think it might be worth to consider the inlining context. Please take a look at the following test case:<br class="gmail_msg">
<br class="gmail_msg">
```<br class="gmail_msg">
define i32 @bar() !dbg !6 {<br class="gmail_msg">
entry:<br class="gmail_msg">
%call = tail call i32 @foo(), !dbg !8<br class="gmail_msg">
ret i32 %call, !dbg !9<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
define i32 @test(i32 %a, i32 %b) !dbg !10 {<br class="gmail_msg">
entry:<br class="gmail_msg">
%tobool = icmp ne i32 %a, 0, !dbg !11<br class="gmail_msg">
br i1 %tobool, label %if.then, label %if.else, !dbg !11<br class="gmail_msg">
<br class="gmail_msg">
if.then: ; preds = %entry<br class="gmail_msg">
%call.i = call i32 @foo(), !dbg !12<br class="gmail_msg">
%sub = sub nsw i32 %b, %call.i, !dbg !14<br class="gmail_msg">
br label %if.end, !dbg !15<br class="gmail_msg">
<br class="gmail_msg">
if.else: ; preds = %entry<br class="gmail_msg">
%call1 = call i32 @foo(), !dbg !16<br class="gmail_msg">
%sub2 = sub nsw i32 %b, %call1, !dbg !17<br class="gmail_msg">
br label %if.end<br class="gmail_msg">
<br class="gmail_msg">
if.end: ; preds = %if.else, %if.then<br class="gmail_msg">
%b.addr.0 = phi i32 [ %sub, %if.then ], [ %sub2, %if.else ]<br class="gmail_msg">
ret i32 %b.addr.0, !dbg !18<br class="gmail_msg">
}<br class="gmail_msg">
```<br class="gmail_msg">
<br class="gmail_msg">
where<br class="gmail_msg">
<br class="gmail_msg">
```<br class="gmail_msg">
!6 = distinct !DISubprogram(name: "bar", ...)<br class="gmail_msg">
!10 = distinct !DISubprogram(name: "test", ...)<br class="gmail_msg">
!12 = !DILocation(line: 4, column: 10, scope: !6, inlinedAt: !13)<br class="gmail_msg">
!16 = !DILocation(line: 11, column: 10, scope: !10)<br class="gmail_msg">
```<br class="gmail_msg">
<br class="gmail_msg">
Here the call instruction in %if.then block is actually inlined from @bar, and if we pickup the scope from that instruction, the final code would be look something like below:<br class="gmail_msg">
<br class="gmail_msg">
```<br class="gmail_msg">
define i32 @test(i32 %a, i32 %b) !dbg !10 {<br class="gmail_msg">
entry:<br class="gmail_msg">
%call.i = call i32 @foo(), !dbg !11<br class="gmail_msg">
%sub = sub nsw i32 %b, %call.i, !dbg !13<br class="gmail_msg">
ret i32 %sub, !dbg !14<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
!6 = distinct !DISubprogram(name: "bar", ...)<br class="gmail_msg">
!11 = !DILocation(line: 0, column: 0, scope: !6, inlinedAt: !12)<br class="gmail_msg">
```<br class="gmail_msg">
<br class="gmail_msg">
As the call instructions are merged and hoisted inside test not bar, it would be awkward if the merged call instruction has a scope of bar, though the debug location is still just (line: 0, column: 0).<br class="gmail_msg">
<br class="gmail_msg">
I missed the discussion in llvm-dev and implemented a patch for the same issue considering inline scope (D29927). Maybe worth take a look.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Repository:<br class="gmail_msg">
rL LLVM<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D29833" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29833</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>