[LLVMdev] Optimization passes and debug info

[Chris Lattner]

On Jul 21, 2008, at 8:21 AM, Matthijs Kooijman wrote:
>> I think that the right answer for llvm-gcc at "-O3 -g" is  
>> (eventually)
>> for debug info to be updated where possible but discarded when
>> necessary as you describe.  For llvm-gcc we really really want the  
>> non-
>> debug related output of the compiler to be identical between "-O3"  
>> and
>> "-O3 -g", and discarding this information is a reasonable way to do
>> this.
> You explicitely mention -O3 here, so I assume you will be wanting  
> different
> behaviour at -O2 and below? For this to work, some kind of gobal is  
> required,
> unless you want different passes to look at the -O commandline  
> directly (which
> sounds really, really bad).

I just meant -O3 as an example.  I'd expect all -O levels to have the  
same behavior.  -O3 may run passes which are more "lossy" than -O1  
does though, and I'd expect us to put the most effort into making  
passes run at -O1 update debug info.

> Any suggestions on where to put this setting? I think making it a  
> property of
> PassManager seems to make sense? This way, the different tools can  
> decide how
> to expose the different settings to the user, and each  
> transformation pass can
> easily access the setting.

No new global needed :)

>> If you're interested in a path forward, I describe one reasonable  
>> one  here:
>> http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt

> There, you mainly describe a single goal: Prevent debugging info from
> interfering with optimizations at all.

Right, the first goal is to make it so that enabling -g doesn't affect  
codegen in any way.  I consider this to be a very important goal.

> When looking at Devang's proposal for a
> three level debugging preservation setting, this would probably  
> correspond to
> level 3.
>
> To recap:
>
> Level 1 Preserve all debug info and ability to single step in a  
> debugger.
> 				If the transformation pass is not able to preserve these then  
> the pass
> 				should skip the transformation.
>
> Level 2 Preserve minimum debug info to help investigate crash reports
> 				from the field (stack traces etc). Here, it is ok if single  
> stepping
> 				capabilities are degraded.
>
> Level 3 Feel free to destroy debug info if it gets in you way.
> 				Here, the pass should not leave misleading debug info in the  
> stream.
> 				If the info can not be fixed as part of transformation then the  
> info
> 				should be just removed.
>
> Are these three levels acceptable? They look so to me.

These three levels are actually a completely different approach, on an  
orthogonal axis (reducing the size of debug info).   I actually  
disagree strongly with these three levels, as the assumption is that  
we are willing to allow different codegen to get better debug info.  I  
think that codegen should be controlled with -O (and friends) and that  
-g[123] should affect the size of debug info (e.g. whether macros are  
included, etc).  If the default "-g" option corresponded to "-g2",  
then I think it would make sense for "-g1" to never emit location  
lists for example, just to shrink debug info.


I think debug info absolutely must not affect the generated code, and  
based on that, has some desirable features:

1. I agree with Alexandre Oliva that the compiler should never "lie"  
in debug info.  If it has some information that is not accurate, it  
should respond with "I don't know" instead of making a wrong guess.   
This means that the debugger either says "your variable is certainly  
here" or it says "I don't know", it never says "your variable might be  
here".

2. Based on #1, it is preferable for all optimizations to update debug  
info.  This improves the QoI of the debugging experience when the  
optimizations are enabled.  However, based on #1, if they can't or  
haven't been updated yet, they should just discard it.

3. On an orthogonal axis (related to -g[123]), if an optimization is  
capable of updating information, but doing so would generate large  
debug info and the user doesn't want it - then it might choose to just  
discard the debug info instead of doing the update.

Does this seem reasonable?

-Chris