This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: loop optimization implementation question
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Caroline Tice <ctice at apple dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 25 Mar 2004 13:09:20 -0500
- Subject: Re: loop optimization implementation question
- Organization: Red Hat Canada
- References: <7143AE4A-7E86-11D8-A3C2-000393BB90B6@apple.com>
On Thu, 2004-03-25 at 13:01, Caroline Tice wrote:
> I thought about doing it in the tree-ssa optimizations, but this
> optimization isn't really a good tree-ssa
> optimization because it changes the shape of the cfg (all the loop
> blocks and split/join edges are removed,
> and replace with a single straight-line flow block containing a
> function call), which means adding a fair amount of
> complexity to fix up all the phi-nodes and ssa variables.
>
Well, yes and no. You do have to mark variables for renaming. I guess
if you're not going to use dataflow and convert loops strictly using
pattern matching, you could do it after we go out of SSA. However, this
will prevent you from converting loops like
for (i)
{
*p++ = 0;
<lots of other unrelated code >
}
> My real question is: should this
> optimization happen before the tree
> gets genericized? After generic but before gimple? After gimple but
> before ssa? Or in ssa?
>
In SSA, using the infrastructure being built by the LNO folks would be
best. It looks to me that we should already have most/all the dataflow
information you'll need for this.
> Also, is anyone working (or has anyone worked) on a similar
> optimization is gcc?
>
Not sure. I wouldn't be surprised if we have some limited support in
some RTL pass.
Diego.