This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Insert on edge comment
- From: law at redhat dot com
- To: Michael Matz <matz at suse dot de>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Fri, 30 May 2003 17:52:56 -0600
- Subject: Re: [tree-ssa] Insert on edge comment
- Reply-to: law at redhat dot com
In message <Pine.LNX.4.44.0305310110570.27582-100000@wotan.suse.de>, Michael Ma
tz writes:
>> In tree-ssa you have to keep the control nesting stuff correct in
>> addition to inserting the new code and redirecting the jumps (and the
>> jumps may be implicit in the control structures rather than explicit in
>> the IR).
>
>I'm sure you know. But this has serious implications for any code moving
>optimization like PRE. For those being able to split edges is crucial.
>I.e. I hope the (obivously) complicated process to implement it is
>worthwhile ;-)
Yes, PRE fundamentally wants to insert on edges. I haven't looked at the
SSA version, but the RTL version has the property that the insertions can
be queued until PRE is complete. This allows you to either update or
rebuild the critical information after PRE is complete.
We're a lot more worried about more radical transformations on the loop
structure.
>> I don't think anyone is saying it's impossible, it just has more
>> complications than doing splitting on a linear form such as RTL.
>
>Hmm. Does this mean, that for instance this expression:
>
> a/b*c+f(g,h(i))
>
>is represented as one tree (seen from the top), which magically has three
>to five (depending on how * and + are defined) outgoing "edges", which
>refer to the following statement resp. the reached exception handler?
>Let's say it this way: ugh. Remind me again: why would we want to do
>basic block based optimizations on such an IR? I'm not pessimistic yet,
>but hiding control flow in this way seems wrong to me, and I would like to
>learn the reasons why it isn't.
That will be represented something like:
t1 = a/b;
t2 = t1*c;
t3 = h(i);
t4 = f(g, t3);
t5 = t3 + t4;
I didn't run it through to verify exact ordering, but it ought to look
something like code above.
When we refer to the control nesting we're referring to things like
SWITCH_EXPRs, COND_EXPRs, TRY_FINALLY_EXPRs and similar objects which
themselves hold other tree nodes.
Jeff