This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering preview
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 27 Aug 2003 22:16:40 +0200
- Subject: Re: [tree-ssa] COND_EXPR lowering preview
- References: <200308271952.h7RJq4Mj009652@speedy.slc.redhat.com> <1062014434.4452.15.camel@frodo.toronto.redhat.com>
Hello,
> > 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.
from "amount of work" point of view, I would slightly prefer a separate
pass too. With cond_exprs I have somehow managed to place it into
gimplification (although even this was more complicated than I thought),
but for switch_expr lowering, this imho would be quite cumbersome.
Zdenek