[llvm] r289468 - Recommit r288212: Emit 'no line' information for interesting 'orphan' instructions.

[Robinson, Paul via llvm-commits]

> -----Original Message-----
> From: aprantl at apple.com [mailto:aprantl at apple.com]
> Sent: Friday, December 16, 2016 2:58 PM
> To: Robinson, Paul
> Cc: llvm-commits; Saleem Abdulrasool
> Subject: Re: [llvm] r289468 - Recommit r288212: Emit 'no line' information
> for interesting 'orphan' instructions.
> 
> 
> > On Dec 16, 2016, at 2:50 PM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: aprantl at apple.com [mailto:aprantl at apple.com]
> >> Sent: Friday, December 16, 2016 2:34 PM
> >> To: Robinson, Paul
> >> Cc: llvm-commits; Saleem Abdulrasool
> >> Subject: Re: [llvm] r289468 - Recommit r288212: Emit 'no line'
> information
> >> for interesting 'orphan' instructions.
> >>
> >> The use-case that this was derived from is the code that the swift
> >> compiler generates for top-level code (In Swift there is no explicit
> >> main() function). The user-written code (with line numbers) and the
> >> language runtime initialization (compiler-generated, line 0) both end
> up
> >> in the main() function. This is why it starts out with line 0 for the
> >> initialization, followed by the code the user wrote with actual line
> >> numbers.
> >
> > So, before my patch, prologue_end gets set on line 0.  That seems weird.
> > The compiler-generated code seems like it ought to be part of the
> > prologue, and so you would want the debugger to stop on the first non-0
> > line (in your example this would be line 14).
> >
> > When you start up a Swift program in the debugger, is the initial stop
> > before or after the compiler-generated init code?  If it's before, is
> > that really what you want?
> 
> What I really want is the prologue_end to be at the first nonzero line.
> Due to practical constraints, this hasn't been an option and having the
> prologue_end on line 0 works, too: LLDB will stop there and then skip
> ahead to the first non-zero line.

I figured that's what was happening.

> 
> In LLVM IR, having the line 0 locations on the compiler-generated
> instructions is mandatory, because the compiler-generated instructions may
> be calls, which may be inlined, and that is only legal if the call
> instruction has a debug location (otherwise we will crash/assert while
> constructing the inline scopes).

If the compiler-generated code can call user-written functions, I see
that could be a problem.  However, that means LLDB would be stopping
either in the user-written function (if it's inlined) or on the first
user-written "main" line (if there's no inlining) so the stopping point
is dependent on optimization, which also seems sub-optimal.  But I don't 
see any way around that, unfortunately. It seems like it could be hard
for the front-end to mark the prologue_end reliably.

> 
> I would be happy with a solution that inserts the prologue_end at the
> first nonzero location, however, since there are inlineable function calls
> and control-flow happening before it, this may be difficult to achieve in
> practice.
> 
> I'm also happy with just going back to the pre-r289468-behavior on this
> testcase.

Fix should be coming soon.
--paulr

> 
> -- adrian
> 
> 
> > --paulr
> >
> >>
> >> -- adrian
> >>
> >>> On Dec 16, 2016, at 2:29 PM, Robinson, Paul <paul.robinson at sony.com>
> >> wrote:
> >>>
> >>> Sure.  I see that the very first debug location is explicitly setting
> >> line 0.  Is that really what you want?
> >>> --paulr
> >>>
> >>> From: aprantl at apple.com [mailto:aprantl at apple.com]
> >>> Sent: Friday, December 16, 2016 2:00 PM
> >>> To: Robinson, Paul
> >>> Cc: llvm-commits; Saleem Abdulrasool
> >>> Subject: Re: [llvm] r289468 - Recommit r288212: Emit 'no line'
> >> information for interesting 'orphan' instructions.
> >>>
> >>> Hi Paul,
> >>>
> >>> we were investigating a test suite regression in the Swift compiler
> >> (just in case you are curious: https://bugs.swift.org/browse/SR-3421)
> that
> >> I could bisect down to this commit.
> >>>
> >>> When compiling the attached IR (which I reduced manually from the full
> >> testcase) llc now runs into a situation where it never sets the
> >> prologue_end flag for the function main().
> >>>
> >>> $llc t.ll -o - | grep '\.loc'
> >>>        .loc    1 0 0
> >>>        .loc    1 14 13
> >>>
> >>> I assume that this is something we never want to happen. Would you
> mind
> >> taking a look?
> >>>
> >>> -- adrian