This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to improve register elimination
- To: John Wehle <john at feith dot com>
- Subject: Re: Patch to improve register elimination
- From: Jeffrey A Law <law at upchuck dot cygnus dot com>
- Date: Thu, 01 Apr 1999 03:35:08 -0700
- cc: egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <199902140512.AAA27876@jwlab.FEITH.COM>you write:
> How is this any different from the case where the offset for fp->sp is
> known in which case update_eliminables doesn't generate any new spills
> since no eliminations changed?
When the offsets are known, the elimination is still safe. Thus no spills are
needed. What I'm worried about is the case where we initially allow an
fp->sp elimination when the offset was unknown in the last block because FP
was initially unused in the last block. Then we later end up (via another
elimination) with a reference to fp in the last block. Which makes our initial
elimination of fp->sp invalid.
> The scenarios are:
>
> 1) Current code ... offsets are all known.
>
> First iteration ap->fp.
> update_eliminables is called, however no eliminations changed.
> finish_spills has nothing to do and returns zero.
> Big loop exits.
This should be fine since all offsets are known and nothing causes us to
initially think an elimination is valid, only to find out later that the
elimination is invalid due to othe changes.
> 2) Current code ... fp->sp offset is not known.
>
> First iteration ap->fp.
> update_eliminables is called, fp->sp elimination changed.
> Big loop iterates again.
> fp->sp elimination still doesn't happen since it was disabled.
Right. Again, I think we both agree this is safe.
>
> 3) My patch ... offsets are all known.
>
> First iteration ap->fp.
> update_eliminables is called, however no eliminations changed.
> finish_spills has nothing to do and returns zero.
> Big loop exits.
>
> This is the same as #1.
Right. Not an issue.
> 4) My patch ... fp->sp offset is not known.
>
> First iteration ap->fp.
> update_eliminables is called, however no eliminations changed.
> finish_spills has nothing to do and returns zero.
> Big loop exits.
>
> The result is the same as #2.
Not the same since you allow fp->sp elimination when the offset is unknown
in the last block and fp is not used in the last block.
If you later end up with a reference to fp in the last block, then I believe
any fp->sp eliminations done earlier need to be undone. I don't see that
your code will undo those previous fp->sp eliminations.
jeff