[LLVMdev] Optimizations and debug info
clattner at apple.com
Mon Nov 3 02:33:23 PST 2008
On Oct 31, 2008, at 1:29 PM, Török Edwin wrote:
> Hi Dan,
> I am actually more interested in Analysis working in presence of debug
> info, but in order to get any meaningful results, you need to run some
> transformations, at least GVN, otherwise loops aren't transformed to
> canonical form either.
> So we could:
> - teach GVN that a dependency on a debug instruction is not a real
> and should ignore it
> - teach GVN to remove stale dbg info due to its transformations
> - if we cannot preserve dbg.stoppoint we may try to preserve
> region.begin() and region.end() [or convert stoppoints to regions]
I'd really like to avoid removing stoppoints unless they are
redundant: two stoppoints that are right next to each other, so they
represent the exact same state. Currently, I'm thinking that it would
make sense to have instcombine zap two stoppoints that are right next
to each other, but would like to avoid zapping them in other cases
unless there is something that is really really hard to deal with.
OTOH, I'm not sure how to best handle global memory updates w.r.t.
stoppoints. Dan is absolutely right that stoppoints represent a point
where we'd like to preserve observable memory state, and so it makes
sense to treat them as memory read points at the least. However, if
we want to preserve stoppoints, then we have to give up on preserving
memory consistency at those stoppoints.
This is a really tricky area with lots of tradeoffs, I don't claim to
have all the answers :)
> Consider you are debugging a crash in optimized code:
> Hey, your program crashed somewhere in function foo in foo.o
> Hey, your program crashed in function foo in region foo1.c:100 -
I think it's a bit worse than this. One of the reasons for my
fondness for line number info has to do with profiling tools like
shark/oprofile. These tools really do benefit a lot from having debug
info for highly optimized code. They don't care at all about variable
values, but it is very useful to have them attribute time samples to
source lines (even if inherently fuzzy).
> Also preserving debug info about variable names can be useful.
>> For llvm.readcyclecounter, I think it's fine to inhibit
>> optimizations. It's hard to understand what it means if it
>> doesn't :-). Do you have an example where being able to
>> do optimizations would be useful?
> I don't have a real example for the readcycles, but I could think
> that a
> profiler wants to profile something, and inserts it and it ends up
> Now, the presence of read_cycle_counter would prevent GVN from working
> in that loop, since read_cycle_counter would be seen as a depedency of
> every load and store (including the one from the induction
> variable). So
> by inserting the read_cycle_counter it pessimized the code, and
> wrong measurements.
I agree with Dan here. These are quite different than debug info:
they really should serve as optimization barriers of a sort. In your
case here, you could always move the timing out of the loop, which is
probably more precise anyway.
More information about the llvm-dev