This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 6 GCC regressions, 2 new, with your patch on 2002-07-20T23:26:42Z.
- From: Jan Hubicka <jh at suse dot cz>
- To: Geoff Keating <geoffk at redhat dot com>
- Cc: jh at suse dot cz, roger at eyesopen dot com, gcc-patches at gcc dot gnu dot org,rth at cygnus dot com, gcc-regression at gcc dot gnu dot org
- Date: Mon, 22 Jul 2002 15:43:16 +0200
- Subject: Re: 6 GCC regressions, 2 new, with your patch on 2002-07-20T23:26:42Z.
- References: <200207210301.g6L31ih19173@maat.sfbay.redhat.com> <Pine.LNX.4.33.0207202158420.21322-100000@www.eyesopen.com> <20020721193843.GD22786@atrey.karlin.mff.cuni.cz> <200207221157.g6MBvOQ14328@desire.geoffk.org>
> > cselib notices the equivalence and cprop actually does the replacement
> > of reg 64 by reg 62. But the REG_EQUIV note is not really valid, as the
> > value of memory copy y is not valid during the function (overwriten by
> > bar call). Just before register allocation the load of register 62
> > appears to be moved just before the assignment. I am not sure who does
> > the movement but it is valid given the information about equivalency
> > with memory.
> >
> > cse.c seems to contain code preventing such a substitution as gcse does,
> > so I am attaching simple patch that does the same for cprop and I will
> > install it as obvious as I am not quite sure whether I will be able to
> > read my email tomorrow.
> >
> > Sun Jul 21 21:35:20 CEST 2002 Jan Hubicka <jh@suse.cz>
> > * gcse.c (do_local_cprop): Do not extend lifetimes of registers set by
> > do_local_cprop.
>
> I think that this patch just papers over the real problem, which is
> that the REG_EQUIV note is not correct; it should be REG_EQUAL. The
> whole purpose of REG_EQUIV notes is that you can always make the
> substitution safely.
My impression too, thats why I sent such a long email. Interestingly
enought we do the trick for a years and all passes (cse/gcse/regmove)
consistently do have such code to avoid extending of REG_EQUIVed
references. As mentioned I made the patch to avoid current compiler
breakage.
How do you think we should behave? I think at the moment we generate
the loads of argument we do not know whether the load can be potentially
changed and we never track the information. So eighter we can kill the
EQUIV notes entirely or add new pass to analyze the generated code and
kill when something is modifying or dereferencing the argument.
I believe this is partly done in the sibcall code that runs into similar
problems and occasionally removes the notes. I would like to hear
opinion from someone who is more familiar with the REG_EQUIV notes
concept than I do before I will do something complex, like extra pass
is.
Honza
>
> --
> - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>