Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  1, 2009, Andrew MacLeod <amacleod@redhat.com> wrote:

> Is there a reason we can't leave the current default behaviour the way
> it is, and have the VTA code simple enable the "best" choices for it.

We don't want options used to control generation of debug information
(say the option that enables or disables VTA) to change the generated
code (say enable or disable coalescing), do we?  This would be as bad as
-g/-g0 generating different code.

Personally, I don't see the point of the options either, but I don't see
the point of the current trade-off either.  Corrupting debug info only
for inlined variables is not really better than corrupting debug info
uniformly.

I'd much rather we optimized as well as we could when asked to optimize
(would save compile-time memory and time too), and take care of
preserving debug information through adequade debug information
infrastructure.

But this would imply changing defaults, and would make it difficult to
compare the performance effects of the additional coalescing.

Or, leaving the default as they are, trivial testcases (little to no
inlining) might give an impression that current debug info doesn't suck
as much as it does, reducing the pressure for better infrastructure.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer