This is the mail archive of the
mailing list for the GCC project.
Re: PATCH for CSE
- To: mark at markmitchell dot com
- Subject: Re: PATCH for CSE
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 02 Jul 1998 00:21:36 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199807012334.QAA25625@smtp.earthlink.net>you write:
> Here's a patch that improves execution time by a factor of three, for
> one loop I've been looking at. It reduces instruction count by a
> similar factor, partly by enabling other optimizations.
> When we had something like:
> (SET (REG 1) (ADDRESSOF (REG 2)))
> (SET (MEM (REG 1)) (REG 3))
> CSE's find_best_addr decided that REG1 was a great address because it
> was already in a register, and (ADDRESSOF (REG 2))) was lousy because
> it had a higer ADDRESS_COST. This patch introduces a new macro, for
> use only in CSE because after that point ADDRESSOFs are purged, which
> favors (ADDRESSOF (REG)). That allows other mechanisms in CSE to
> simplify (MEM (ADDRESSOF (REG 2))) to just plain REG 2.
I'm not sure if this is safe. Consider if the ADDRESSOF was used
because we needed to take the address of a local variable and pass
it to a subroutine. Then assume the subroutine stores into the the
Later we have a read of that variable via (mem (adddressof (reg)) that
we turn into (reg) and miss the side effect of the subroutine call we
just made. In fact, we've already got a bug of this nature that was
reported yesterday :(
Seems to me this is only safe if we can eliminate every addressof for
a particular register.
I think we can create (mem (addressof (reg)) expressions in cse, but
we can't collapse it into (reg) until we purge the addressof expressions..