This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] More REG_EQ* notes cleanups
- From: "Roger Sayle" <roger at eyesopen dot com>
- To: "Grigory Zagorodnev" <grigory_zagorodnev at linux dot intel dot com>
- Cc: "Steven Bosscher" <stevenb dot gcc at gmail dot com>, gcc-patches at gcc dot gnu dot org, zadeck at naturalbridge dot com
- Date: Mon, 12 Feb 2007 17:16:56 -0700 (MST)
- Subject: Re: [PATCH] More REG_EQ* notes cleanups
- References: <200702111443.33920.steven.bosscher@gmail.com> <45D0621D.8060506@linux.intel.com>
Hi Grigory,
On Mon, February 12, 2007 5:48 am, Grigory Zagorodnev wrote:
> Steven Bosscher wrote:
>> The patch is mostly mechanical, but there is one interesting change
>> to local-alloc.c. We used to turn REG_EQUAL notes into REG_EQUIV
>> notes if the note datum was invariant. But this is wrong if there
>> is more than one set to the register that the REG_EQUAL note applies
>
> Unfortunately this patch resulted in output miscompare for two spec
> cpu2006 benchmarks 464.h264ref and 482.sphinx3 on i386-redhat-linux.
>
I'm not sure if Steven's been in touch with you privately, but I was
wondering whether you could test whether reverting just the local-alloc.c
changes are sufficient to resolve the regression? This is the only part
that was more than a clean-up and may have resulted in a functional change
[a latent RTL bug that I worried about in my review/approval]. If it's
not the local-alloc.c change, then each of the other file's modifications
are independent and can be applied/reverted independently to identify
which hunk is problematic.
I think the clean-up of REG_EQ* notes is a good thing, so to avoid
reverting the entire patch, it'd be good to narrow down the cause/location
of the problem.
Many thanks in advance. Sorry I don't have access to cpu2006 or I'd offer
to help in the investigation myself.
Roger
--