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

[Robinson, Paul]

Ping.

________________________________________
From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] on behalf of Robinson, Paul [Paul.Robinson at am.sony.com]
Sent: Friday, September 21, 2012 3:36 PM
To: llvm-commits at cs.uiuc.edu
Subject: [llvm-commits] [PATCH] Improve debug-line info at -O0

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ISel-dbg-line-diff.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120926/d87c2fa3/attachment.txt>