[LLVMdev] Optimization passes and debug info

[Matthijs Kooijman]

Hi Chris,

> 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.
I'm not really sure that you could divide passes into "lossy" and "not so
lossy" that easily. 

For example, SimplifyCFG will be run at every -O level.  This would imply that
it must be a "not so lossy" pass, since we don't want to completely thrash
debugging info at -O1.

However, being "not so lossy" would probably mean that SimplifyCFG will have
to skip a few simplifications. So, you will have to choose between two goals:
	1) -g should not affect the outputted code
	2) Transformations should preserve as much debug info as possible

I can't think of any way to properly combine these goals. It seems that goal
1) is more import to you, so giving 1) more priority than 2) could work out,
at least for the llvm-gcc code which defines optimization levels in this way.

However, I can imagine that having a -preserve-debugging flag, in addition to
the -O levels, would be very much welcome for developers (which would then
make goal 2) more important than 1)). Perhaps not so much as an option to
llvm-gcc, but even more so when using llvm as a library to create a custom
compiler. 

Do you agree that goal 2) should be possible (even on the long term), or do
you think that llvm should never need it? In the latter case, I'll stop
discussing this, because for our project we don't really need it (though I
would very much like it myself, as an individual developer).

Say we do want goal 2) to be possible (of course not at the sime time as goal
1)), some kind of debugging preservation level is required AFAICS (Can't
think of any other solutions anyway). Now, even if we think that goal 1) is
more important on the short term, I would still suggest implementing this
level right now. Even though support for goal 2) will not be complete right
away (we can focus on 1) first), easy cases could be caught right away. I'm
afraid that only focussing on 1) now and later adding 2) might cause a lot of
extra work and missed corner cases. However, I might be completely
miscalculating this. If you think that this will not be a problem, or not a
significat problem, I'll stop discussing it as well, and just commit my
changes to get us to goal 1).

> These three levels are actually a completely different approach, on an  
> orthogonal axis (reducing the size of debug info).
I'm not really sure what you mean with this. The idea behind the levels is to
find the balance in the optimization vs debug info completeness tradeoff.

I totally agree with keeping debug info consistent in all cases. Problems
occur when an optimization can't keep the debug info full consistent: It must
then either remove debug info or refrain from performing the optimization.

These levels will determine the balance between those two levels. Throwing
away more debug info will obviously reduce the size of the debug info, but
that's in no way a goal and only a side product.

> 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.
Yes, this is indeed a tradeoff that I want to be able to make (see above).
This seems to be the fundamental point in this discussion :-)

> 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 that having the multiple -g options you describe is yet another axis,
that is related to which debug info is generated in the first place.

> 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.
I'm not sure when an optimization would be generating "large debug info", but
I'm not talking about any such thing.

> Does this seem reasonable?
I think we're at least getting closer to making our points of view clear :-)

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/20080723/e1813b15/attachment.sig>