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: 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
--


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