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
