This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering preview
- From: Jason Merrill <jason at redhat dot com>
- To: law at redhat dot com
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Diego Novillo <dnovillo 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 16:45:45 -0400
- Subject: Re: [tree-ssa] COND_EXPR lowering preview
- References: <200308272021.h7RKLAl7009867@speedy.slc.redhat.com>
On Wed, 27 Aug 2003 14:21:10 -0600, email@example.com wrote:
> In message <20030827201640.GA13443@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
> >> > 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.
> Well, then let's make it separate lowering pass.
For switches, OK, but there's already code to do COND_EXPR lowering in the
gimplifier in order to handle && and || semantics. I really don't want
two copies of that code floating around the compiler.