This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Put scope blocks on a diet
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 27 Nov 2007 12:08:23 -0800
- Subject: Re: Put scope blocks on a diet
- References: <orlkcucny9.fsf@oliva.athome.lsd.ic.unicamp.br> <20070806201102.GF4460@kam.mff.cuni.cz> <orprzw2kuk.fsf@free.oliva.athome.lsd.ic.unicamp.br> <orprznl6tl.fsf@free.oliva.athome.lsd.ic.unicamp.br> <20071010084624.GA19060@atrey.karlin.mff.cuni.cz> <orzlyqjhq1.fsf@free.oliva.athome.lsd.ic.unicamp.br> <84fc9c000710110138i7e541407p26ff63fbcc76028a@mail.gmail.com> <20071011221238.GN20381@kam.mff.cuni.cz> <orir5dglqw.fsf@free.oliva.athome.lsd.ic.unicamp.br> <20071012061351.GA11752@atrey.karlin.mff.cuni.cz> <84fc9c000711270520n4e75f4b5idc1a8327f0ad2ba2@mail.gmail.com> <oroddfbis2.fsf@oliva.athome.lsd.ic.unicamp.br>
Alexandre Oliva wrote:
>> there is a 50% increase in memory consumption and a 5% increase in
>> compile-time for tramp3d.
> For the record, two points:
Alexandre, please take the rhetoric down a notch. I know you have
strong feelings about this, but you're among friends. :-)
> 1. this patch prevents non-empty blocks with referenced variables from
> being dropped. This was a bug, and it may have given the impression
> that the memory reductions achieved through the earlier, buggy patch
> that IIRC went in on July 24 was correct. But dropping too much
> information was a mistake. We could decide it's ok and desirable to
> drop such information, but it has to be a conscious decision, not an
> accidental fallout from a bug.
That certainly makes sense. Do you have a URL for the July 24 patch?
Meanwhile, please revert your patch. We don't want to oscillate too
much. Is there a PR for the problem that your patch fixed? If not,
please sure that there is one.
> I don't think letting -g or -g0 affect the executable code output by
> the compiler is acceptable.
I don't either. But, we don't have agreement on how best to solve the
problem. So, let's a get PR open, which will help ensure we solve the
problem before the release, and then let's talk about how we can solve it.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713