COND_EXPRs in GIMPLE code and vectorizer

[Paolo Bonzini]

> Yes.  This is also true for a few other expressions.  IIRC, the
> gimplifier expands MAX_EXPR into control flow, even though it is legal
> gimple.

In fact it did this, but later it was removed from the gimplifier 
because it generated worse code.

> The usual reason for this type of thing is that the ability to have
> them as the RHS of a MODIFY_EXPR was added much later than the
> gimplifier, and it was decided that in order to avoid possible
> performance regressions, the existing behavior of lowering wouldn't be
> changed.
> 
> If, of course, there is some good reason to always use the data
> dependent form over the control dependent form, we're always willing
> to explore changing the gimplifier to not do the lowering.

MIN_EXPR/MAX_EXPR in fact are a very good example, because we discovered 
that it would be best not to do the lowering.  In fact, there was no 
reason why the optimizers would mishandle MIN_EXPR and MAX_EXPR (they 
are just like any other tcc_binary node).  If we had a tree combiner, it 
would probably be better to allow COND_EXPR throughout the whole 
compilation, and possibly to generate them from simple phi's like we do 
in the tree-ssa-phiopt pass.  This would leverage some code in fold.

Paolo