This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering preview
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: 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 14:21:10 -0600
- Subject: Re: [tree-ssa] COND_EXPR lowering preview
- Reply-to: law at redhat dot com
In message <20030827201640.GA13443@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>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.
Well, then let's make it separate lowering pass.
jeff