This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] COND_EXPR lowering preview


Hello,

> >  >> 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.

its 10 lines of code, so I don't think this is much of a problem.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]