This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Store motion rewrite
- From: Richard Henderson <rth at redhat dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 3 Mar 2003 16:54:34 -0800
- Subject: Re: [patch] Store motion rewrite
- References: <20030214201246.GA21900@atrey.karlin.mff.cuni.cz> <200302142044.PAA27066@makai.watson.ibm.com> <20030224231329.GA13683@atrey.karlin.mff.cuni.cz> <20030301015207.GJ25419@redhat.com> <20030303233750.GA31160@atrey.karlin.mff.cuni.cz>
On Tue, Mar 04, 2003 at 12:37:50AM +0100, Zdenek Dvorak wrote:
> no, its much simpler; just
> (insn 177 176 374 33 0x2a98de5b40 (set (mem/s:SI (plus:DI (reg/v/f:DI 59 [ this ])
> (const_int 40 [0x28])) [17 <variable>.pos+0 S4 A64])
> (reg:SI 121)) -1 (nil)
> (expr_list:REG_EH_REGION (const_int 1 [0x1])
> (nil)))
>
> is converted into
>
> (insn 431 176 374 33 (nil) (set (reg:SI 169)
> (reg:SI 121)) -1 (nil)
> (nil))
> by store motion.
>
> Unfortunately probably the only correct fix is to disable the
> transformation in this case at all; which is unpleasant considering that
> we will miss most of the opportunities :-(
Yep. There's no helping the fact that you can't perform
load or store motion on trapping memories when they matter.
What we *should* do is have a global optimization pass that
discovers which memories cannot trap due to being shadowed
by another memory which would have trapped first.
Also, I think Andrew Haley has a patch to allow the Java
front end to do more annotation on memories that are known
to not trap, but that has not gone in.
r~