[LLVMdev] Optimization passes and debug info

[Matthijs Kooijman]

Hi Chris,

> > From this observation, I think it might be useful to have some kind  of
> > global flag that tells transformations whether it is allowed to remove
> > debugging code in favour of optimizations. When we start making
> > transformation passes debug-info aware, I think the need for something
> > like this might  increase.
> 
> 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).

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.

> 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. 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.

I think it is important to define these levels and a setting for them now,
before any work starts on making transformations preserve any debugging info.
Alternatively (which I think your proposal implicitely states) passes could
just assume level 3, and once we get that working properly, we can worry about
the other levels. However, in a lot of cases it should be fairly trivial to
support all three levels, so it would be stupid not to implement all of them
at the same time. For the cases where level 3 is significantly easier, we
could implement just level 3 and add TODOs for the other levels.

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080721/1bbb4fcb/attachment.sig>