[PATCH]: Improved handling of COND_EXPR in middle-end passes

Roberto COSTA roberto.costa@st.com
Wed Nov 22 14:10:00 GMT 2006

Beside the if-conversion for the vectorizer, which are the passes that 
make a better job when COND_EXPRs are allowed on the rhs as opposed to 
handling explicit control-flow?
It's an open question, I don't know the answer.

This is a succinct (and likely incomplete) summary of the current 
attitude towards COND_EXPRs on the rhs (again, I'm not taking the 
vectorizer into account):
*) gimplify simplifies them all into explicit control-flow;
*) some folding functions generate them explicitly (I mean from code 
with no COND_EXPRs);
*) some passes do not handle them, but they could easily do that (this 
patch goes into this direction);
*) some passes do not handle them, and they would need to be deeply 
restructured to deal with them, namely dom and jump threading.

If there is no evidence that rhs COND_EXPRs enhance some of the 
optimization passes (while we know they limit jump threading 
possibilities), then it makes sense to me not to allow them in GIMPLE.
But if there is and the decision is to keep them, I'd extend the 
existing passes to support them fully, at least when this can be easily 
done (and this is precisely what the patch does).

Just more food for thoughts...


Diego Novillo wrote:
> 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?

More information about the Gcc-patches mailing list