[llvm-commits] [PATCH] Improve debug-line info at -O0

[Eric Christopher]

Lovely. I'll take a look and see where this gets me.

*sigh*

-eric

On Tue, Oct 2, 2012 at 4:29 PM, Robinson, Paul
<Paul.Robinson at am.sony.com> wrote:
> As it happens I recently ran gdb-7.2 test suite against r164407.
> So I built r165060 and ran it again.  Sadly, not quite 300 more failures.
> (This is on my Ubuntu 10.04 desktop, x86_64.)
> A quick glance through a diff of the summaries shows that a few test
> groups with "step" in the name did have improvements, but many more
> groups had regressions.  I haven't time today to look into any specifics.
> --paulr
> ________________________________________
> From: Eric Christopher [echristo at gmail.com]
> Sent: Tuesday, October 02, 2012 2:26 PM
> To: Robinson, Paul
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] [PATCH] Improve debug-line info at -O0
>
> So I just committed a bunch of patches that seem to do this in a
> slightly different way, I'm going to keep my eyes open for fallout and
> if you could take a look as well I'd appreciate it.
>
> -eric
>
> On Mon, Oct 1, 2012 at 1:12 PM, Robinson, Paul
> <Paul.Robinson at am.sony.com> wrote:
>> Thanks! Yeah, there are some unobvious things going on here, it took me
>> 3-4 tries to get it working locally.
>> --paulr
>>
>> ________________________________________
>> From: Eric Christopher [echristo at gmail.com]
>> Sent: Sunday, September 30, 2012 4:32 PM
>> To: Robinson, Paul
>> Cc: llvm-commits at cs.uiuc.edu
>> Subject: Re: [llvm-commits] [PATCH] Improve debug-line info at -O0
>>
>> I'm looking at this, I've just wanted to do some thinking on it first.
>>
>> Thanks.
>>
>> -eric
>>
>> On Fri, Sep 21, 2012 at 3:36 PM, Robinson, Paul
>> <Paul.Robinson at am.sony.com> wrote:
>>> The attached patch corrects some inconsistencies in debug-line info
>>> at -O0, which is produced by FastISel.
>>> Short explanation for the commit log:
>>> Make FastISel attach reasonable debug-line info to local-value
>>> instructions.
>>>
>>> The possibly too long explanation for reviewers:
>>> FastISel generally works backwards through the block. However, when it
>>> generates an instruction to materialize a constant into a register
>>> (calling it a "local value"), it puts that instruction at the top of
>>> the block, for opportunistic reuse. FastISel does not attach source
>>> info to these local-value instructions, because the order of the
>>> local-value instructions does not reflect a good debugging order,
>>> especially at -O0, which is when FastISel is actually used.
>>> Because these instructions lack source info, they implicitly get the
>>> source info from the last physically preceding instruction that does
>>> have source info. If the local-value instructions are at the top of
>>> the block, they inherit the source info from the last instruction(s)
>>> of the preceding block. This is not necessarily a sensible source
>>> location for the current block, especially if the flow of execution
>>> is not simply falling through from the preceding block.
>>> In many cases it appears that GDB will do something reasonable anyway,
>>> but our debugger is not quite so forgiving, so I developed a patch to
>>> attach the source info from the first non-local-value ("real")
>>> instruction to the first local-value instruction, which will cause all
>>> the local-value instructions to appear to come from the same source
>>> statement as the first real instruction in the block.
>>> There are three additional gotchas here.
>>> First, if FastISel emits a call, it will flush any local-value
>>> instructions, so those registers don't have to be live across the
>>> call. In effect, the call creates a sub-block and we should attach the
>>> post-call line number to the local-value instructions for each
>>> sub-block.
>>> Second, if we've finished a block (working backwards, remember) but
>>> the local-value instructions aren't actually the first instructions in
>>> the block (e.g. there are prolog instructions for an entry block), the
>>> instructions that _are_ at the top of the block probably do have
>>> source info, and we're better off just letting the local-value
>>> instructions inherit that line number.
>>> Finally, if we've finished a block and the local-value instructions
>>> really are at the top of the block, but this is an entry block, then
>>> the correct entry point line number will be attached to the top of the
>>> block by code somewhere else, and so we shouldn't attach one during
>>> FastISel. ("Why doesn't FastISel have the correct entry point line
>>> number?" you ask. I don't know; I just found out my patch wasn't doing
>>> the right thing and avoiding the top of an entry block caused the
>>> right thing to happen.)
>>>
>>> Please review, and commit if okay.
>>> --paulr
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>