This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Roberto COSTA <roberto dot costa at st dot com>, Roger Sayle <roger at eyesopen dot com>, Ian Lance Taylor <ian at airs dot com>, Andrew MacLeod <amacleod at redhat dot com>, GCC patches mailing list <gcc-patches at gcc dot gnu dot org>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Thu, 7 Dec 2006 02:18:57 +0100
- Subject: Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- References: <email@example.com> <20061122132938.GA3683@atrey.karlin.mff.cuni.cz> <456ABF4D.firstname.lastname@example.org> <456AFD49.email@example.com>
> Roberto COSTA wrote on 11/27/06 05:34:
> >then, as a write-after-approval maintainer, I formally request the
> >approval to check in the patch.
> The mere act of submitting a patch implies a formal request for approval.
> Two different opinions do not imply consensus. I'm inclined to agree
> with Zdenek, but I also wonder whether the savings are significant to
> justify the added complexity sprinkled everywhere we need to support
> Why is this better than just converting the IFs when needed?
I just came over another situation in that support for rhs COND_EXPR
makes things easier: Some loops may have # of iterations expressed as
(n <= 0 ? 1 : n). If we need to use this expression for number of
iterations (which e.g. vectorizer needs), if COND_EXPR may be used on
rhs this is no problem. If this were not allowed, to emit this
expression to the program, we would need to alter cfg (which may be
quite cumbersome). Of course, it might also make semse to allow rhs
COND_EXPR only in some optimization passes and lower them afterwards.