[tree-ssa] COND_EXPR lowering preview
Diego Novillo
dnovillo@redhat.com
Wed Aug 27 22:46:00 GMT 2003
On Wed, 2003-08-27 at 15:52, law@redhat.com wrote:
> In message <1062013399.4452.7.camel@frodo.toronto.redhat.com>, Diego Novillo wr
> ites:
> >On Tue, 2003-08-26 at 14:53, Zdenek Dvorak wrote:
> >> It disables control structures removal in dce; this also has to be
> >> handled separately.
> >>
> >What does this have to do with COND_EXPR lowering?
> A lot actually. If you have lowered COND_EXPRs, then there is very little
> value in tracking control dependencies in DCE.
>
Ah, OK. Is this the thread about not using the control parent
relationship in DCE? I guess we can always do the traditional DCE and
build dominance frontiers in the reverse CFG (Cytron's original
SSA-DCE).
> >> COND_EXPR lowering is being done in gimplification; if you like/dislike
> >> it, cry -- I personally have no opinion whether it should be done there
> >> or somewhere later.
> >>
> >I still think we should separate this from the gimplifier. We should
> >probably have a single lowering pass that runs immediately before we
> >build the flow graph.
> I don't see the value in having it separate. All that does is force
> another walk over the statements, which seems awful wasteful. I'd
> prefer to see this lowering happen during gimplification.
>
We are going to be doing separate lowering pass with EH. We can
piggyback all the lowering code in there.
The reason I tend to prefer this is more stylistic than anything else.
The only example I had in mind was code analysis. The purist in me
would like to have a clean separation between GIMPLE as an IL and the
lowering of GIMPLE to benefit our scalar optimizers. Since we are
already going to do a separate lowering pass, we could do it there.
But, as I said before, I'm not that opposed to doing it in the
gimplifier. I don't have a strong technical reason now, so I'm happy
with what the majority thinks it's best.
Diego.
More information about the Gcc
mailing list