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 29, 2007 6:23 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Alexandre Oliva wrote:
> > On Nov 28, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
> >
> >> True -- but it is consistent across runs and across hosts.  Unless the
> >> UIDs vary when you add -g, which, empirically, they do.
> >
> > For the record, before the July 2[46] patch, they didn't.
>
> That's an important fact.  Given that, it's certainly not surprising
> that we have algorithms that previously generated the same code with and
> without -g, but now differ.
>
> It sounds like we have three choices:
>
> 1. Revert the July patches and declare that (for now) DECL_UIDs must not
> be influenced by -g.  Pros: -g doesn't affect generated code.  Cons:
> compiler uses more memory than it does now, though no more than 4.2.
>
> 2. Accept that (for now) -g may affect generated code.  Pros: compiler
> users less memory.  Cons: -g affects generated code.
>
> 3. Do something that makes us depend, at most, on DECL_UID order -- but
> not on exact values.  Pros: -g doesn't affect generated code, compiler
> uses less memory.  Cons: have to do something hard.
>
> Is that right?  Nobody's going to like either (1) or (2) -- but as RM,
> if I have to choose, I'm probably going to pick (1) because I think the
> -g principle is critical.

I also would pick (1) for now, as ...

> Richard has done some version of (3) that he thinks isn't suitable for
> Stage 3.  Richard, can you say what's risky about your patch?  Given
> that nobody is going to like either choice (1) or choice (2), is your
> patch worth considering?

... the patch doesn't fix all of the problems, so we would still generate
different code with -g0 compared to -g.  Also the patch makes the
referenced_vars we iterate over dependent on garbage collection
(because referenced_vars is only a conservative estimate of the referenced
vars and may contain unreferenced ones).  This may cause new problems
which would require to re-compute referenced_vars before we rely on
them being stable.

So the patch is definitely not appropriate for stage3.

Richard.


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