COND_EXPRs in GIMPLE code and vectorizer

[Roberto COSTA]

Paolo Bonzini wrote:
> 
>> 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.

If time allows me, I'd like to try to see what happens if COND_EXPRs are 
kept throughout the GIMPLE passes (I confess I'm curious). Logically, I 
see them as richer constructs (they carry more information than the 
equivalent control-flow code), like MIN_EXPRs and MAX_EXPRs.
I understand there may be additional occasions (currently unexploited) 
to generated COND_EXPRs, but why precisely do you expect unlowered 
COND_EXPRs be potentially harmful?
What do you mean by "tree combiner"?

Cheers,
Roberto