Re: [tree-ssa] COND_EXPR lowering preview

[Diego Novillo <dnovillo at redhat dot com>]

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.