This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR optimization/13653
- From: Jeffrey A Law <law at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 01 Jun 2004 00:19:30 -0600
- Subject: Re: [PATCH] Fix PR optimization/13653
- Organization: Red Hat, Inc
- References: <10406010429.AA14357@vlsi1.ultra.nyu.edu>
- Reply-to: law at redhat dot com
On Mon, 2004-05-31 at 22:29, Richard Kenner wrote:
> Right. And presumably that's what's happening in this case -- ie, we
> have a reg which is set by the initialization in a loop and we're
> somehow determining that the initialization sequence looks like a GIV.
> And we're doing this even though we've set TREE_READONLY on the
> object. Right?
>
> Eric explained this. We have something like:
>
> for (i = 0; i < j; i++)
> {
> const int k = i * 4;
>
> K is a giv. But it's also readonly.
OK. I suspected it was probably something like this, but I must have
missed a message from Eric which made that clearer.
So the question now is whether or not it's worth recording such a
GIV in the first place. And if we decide that recording a GIV which
is marked with TREE_READONLY is valid, what transformations do we
allow using that GIV.
Not recording the GIV if it is marked TREE_READONLY seems relatively
simple and I would expect it to not muck things up.
Clearly if we record the GIV we need to define what transformations
we can make on the GIV and what those transformations do to the
various flags associated with the GIV.
Jeff