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>, GCC patches mailing list <gcc-patches at gcc dot gnu dot org>, Roger Sayle <roger at eyesopen dot com>, Ian Lance Taylor <ian at airs dot com>, Andrew MacLeod <amacleod at redhat dot com>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Wed, 22 Nov 2006 14:29:38 +0100
- Subject: Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- References: <firstname.lastname@example.org>
> I'm starting to wonder if it wouldn't be better to disallow
> lval = COND_EXPR
> in GIMPLE. Passes that benefit from this (if-conversion for the
> vectorizer) could temporarily break this rule to get extended BBs.
> But I'm not convinced either way. Not allowing COND_EXPRs on the RHS of
> an assignment would certainly make life more difficult for these passes.
there certainly are cases where one of the representations is easier to
handle than the other one. In some situations, lval = COND_EXPR however
expresses more precisely the intent, and it also consumes less memory
than expanding it to equivalent cfg representation. I would be in favor
of keeping this construction allowed, unless there are some significant
problems with it.