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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  2, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> On Mon, Jun 1, 2009 at 9:23 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>> 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

> Me neither, and I am opposed to adding it.

I'm missing your rationale here as well.  It would help if you at least
voiced what you suggest we do instead.


Do you propose we keep on sacrificing run-time performance in favor of
debug info that users might not even be interested in (say, compile with
-O3 -g0), rather than trivially permitting the user to easily tune for
one or the other?


We don't even have evidence that the current trade-off is useful for
users.  It sacrifices performance to make for better debug info, but
then it screws debug info all over (we inline a lot) to save
compile-time performance.

We might as well not sacrifice any performance whatsoever, compile- or
run-time.  That would at least make sense when explained to a user.  The
âoh, but if it's inlined, we don't careâ rule that's implemented might
have made sense when GDB couldn't display info from inlined variables.
Now it does, so we can no longer hide behind its shortcoming.

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