This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: unsharing rtl too early
- To: law at cygnus dot com, gcc-patches at gcc dot gnu dot org, Alexandre Oliva <aoliva at cygnus dot com>
- Subject: Re: unsharing rtl too early
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 24 May 2000 13:54:21 +0100
- Cc: Richard Henderson <rth at cygnus dot com>, Geoff Keating <geoffk at cygnus dot com>
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
[sorry to those of you who received this twice, I didn't add the full cc
list last time]
unshare_all_rtl is now re-called from unshare_all_rtl_again. Shouldn't
there be code in there to call reset_used_flags on the new things we
unshare so that we can correctly re-unshare everything?
R.
>
> In message <orhfbt7zii.fsf@tamanduatei.dcc.unicamp.br>you write:
> > --=-=-=
> >
> > On May 20, 2000, Richard Henderson <rth@cygnus.com> wrote:
> >
> > > On Sat, May 20, 2000 at 07:24:42AM -0300, Alexandre Oliva wrote:
> > >> * emit-rtl.c (unshare_all_rtl): Store the copied rtx.
> >
> > > Bwahaha. Yes, this is obviously ok.
> >
> > Nevertheless, it was not enough to fix gcc.dg/980816-1.c, as I've
> > noticed a few minutes ago. The problem was that, in the original
> > testcase, both variables referenced in the divmod insn were
> > virtual-stack-vars, not virtual-incoming-args, so they were not
> > unshared.
> >
> > Here's a patch that arranges for decls to be unshared too, thus fixing
> > the testcase on mn10300. Ok to install?
> >
> >
> > --=-=-=
> > Content-Type: text/x-patch
> > Content-Disposition: inline; filename=unshare-decls.patch
> >
> > Index: gcc/ChangeLog
> > from Alexandre Oliva <oliva@lsd.ic.unicamp.br>
> >
> > * emit-rtl.c (unshare_all_decls): New function.
> > (unshare_all_rtl): Call it.
> Basically OK.
>
> > +/* Go through all virtual stack slots of a function and copy any
> > + shared structure. */
> > +static void
> > +unshare_all_decls (let)
> > + tree let;
> > +{
> Choose something other than "let" for the parameter name -- I have no idea
> what "let" is supposed to stand for :-) "blocks" might be a better name
> for that parameter.
>
> jeff
>