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

[Eric Christopher]

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
>>