[LLVMdev] Optimizations and debug info

Chris Lattner clattner at apple.com
Mon Nov 3 08:00:31 PST 2008

On Nov 3, 2008, at 5:22 AM, Török Edwin wrote:
>> 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.

Yes, you need it for correct output, but in practice, we can't provide  
that at high optimization levels.  At least we can't do that if we  
preserve the guarantee that turning on debug info should not affect  
the generated executable code.

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

Yes, I think it is very important that the presence of debug info not  
affect generated code.


More information about the llvm-dev mailing list