This is the mail archive of the
gcc-patches@gcc.gnu.org
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: <45644716.6050701@redhat.com>
Hello,
> 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.
>
>
> Thoughts?
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.
Zdenek