On 2008-11-03 12:33, Chris Lattner wrote:> 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.
>>
>
> Right.
>
>
>> So we could:
>> - teach GVN that a dependency on a debug instruction is not a real
>> one,
>> 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 :)
>
>
I think we should make a difference somehow between the 3 cases of debug
info use:
- you single-step in gdb
- you just want to get a meaningful stacktrace when the program crashes
- you just want to get source:line info associated with an instruction
(e.g. your shark/oprofile situation below)
For the first case you need the memory consistency, and everything you
described above.
For the last two I think we could use a "best effort" approach of
preserving debug info where possible during optimizations,
but I'd rather see the debug info removed than my code pessimized
;)>> Consider you are debugging a crash in optimized code:
>>
>> Hey, your program crashed somewhere in function foo in foo.o
>>
>> vs.
>>
>> Hey, your program crashed in function foo in region foo1.c:100 -
>> foo1.c:120
>>
>
> 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).
>
Yes, I need something similar to that too, see above. (Analysis pass
that can give messages containing original source:line info).
>
>> Also preserving debug info about variable names can be useful.
>>
>> http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt
>>
>
> See also:
> http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt
>
> :)
>
>
Thanks for the pointer.
>>> 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
>> with:
>>
>> loop
>> ...
>> read_cycle_counter
>> call_to_function
>> read_cycle_counter
>> ....
>>
>> 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
>> getting
>> 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.
>
Ok.
Best regards,
--Edwin