This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for PR target/28604 (cse.c change)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: paul at codesourcery dot com, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 28 Sep 2006 08:43:31 -0600 (MDT)
- Subject: Re: Patch for PR target/28604 (cse.c change)
Hi Steve,
On Mon, 25 Sep 2006, Steve Ellcey wrote:
> This patch needs a good review because my only justification for the
> change is that it fixes the bug and does not cause any regressions.
> I don't really understand why it would be the right thing to do.
I started composing this e-mail listing what I thought the possible
problematic interactions could be, but decided to read the bugzilla
PR before posting, only to discover that something strange is clearly
going on.
Could you post the before and/after 20050604-1.c.112r.cse1 to identify
the significant code generation difference that resolves the issue, or
identify where we begin to get different RTL? I'm aware of several
potential issues in cse.c, but none seem to account for the strange
behaviour you are seeing. Perhaps having additional elements in the
hash table is causing us to make unrelated "canonicalization" or
register equivalence choices.
> + else if (REG_P (XEXP (x, 0))
> + && (regno = REGNO (XEXP (x, 0)) == FRAME_POINTER_REGNUM
> + || regno == HARD_FRAME_POINTER_REGNUM
> + || regno == ARG_POINTER_REGNUM))
I was originally going to suggest that it might make sense to use
REGNO_PTR_FRAME_P here, but I'm not sure this isn't papering over
some unrelated problem. The REG case in cse.c's invalidate doesn't
look like it understands that clobbering STACK_POINTER_REGNUM also
invalidates (or may invalidate) FRAME_POINTER_REGNUM, etc... But
this may be a red herring.
Thanks in advance,
Roger
--