This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Jun  1, 2009, Andrew MacLeod <> 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

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

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
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]