This is the mail archive of the gcc-patches@gcc.gnu.org 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: Put scope blocks on a diet


On Nov 27, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

>> Let's please revert the patch that introduced the bug in the first
>> place.  Then we can make an assessment of how much the memory
>> optimization patch actually gets us without anyone being confused by
>> the distortions caused by the bug in the patch.

> ?  So you mean comparing the current state with the !inline_completed
> part removed to a version that doesn't remove unused scope blocks at all?
> That is, what remains in memory savings?

Yes.  Not being fooled by the excessive memory savings caused by the
bug.

> This particular part of the patch is just a workaround, and as you don't
> have a testcase that breaks (apart from make bootstrap-debug)

On what grounds do you disregard maek bootstrap-debug as a testcase?
Do you know of any other mechanisms we have to detect changes in
generated code caused by enabling debug information?

> Nevertheless memory-usage for non-debug builds of applications are
> an existing issue.

I never said it wasn't.  I just don't think it justifies breaking the
-g/-g0 principle.

> I have a technically more sound patch (those were already posted as
> queued for 4.4), and I am going to see if they fix the make bootstra-debug
> regression.

Is it going to cause decl uids to vary with or without debug info?
This would be very unfortunate and IMHO highly undesirable.

> So if you consider that regression important enough I'd rather
> go with a real fix than a workaround with the memory penalty.

That's fine with me.  I'm not opposed to memory savings, obviously.
What I'm opposed to is sacrificing fundamental requirements for the
sake of memory savings.

>> Also, considering how much scope information that patch causes us to
>> unintentionally discard, do we consciously want to introduce such a
>> major debug information regression in GCC 4.3, even with -O0?

> I am not proposing to revert this part of the patch.

I didn't see anyone saying "please revert one part of the patch".  I
saw people panicing and jumping to demand the whole patch to be
reverted, before it was even understood that this would bringing back
the far more fundamental regression the patch was meant to fix.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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