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

[Robinson, Paul]

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
>