Martin Liška <mli...@suse.cz> writes: > Hi. > > The patch introduces couple of new TREE_CODEs that will help us to have > a proper GIMPLE representation of current VECT_COND_EXPR. Right now, > the first argument is typically a GENERIC tcc_expression tree with 2 operands > that are visited at various places in GIMPLE code. That said, based on the > discussion > with Richi, I'm suggesting to come up with e.g. > VECT_COND_LT_EXPR<COND_LHS, COND_RHS, IF_CLAUSE, ELSE_CLAUSE>. Such a change > logically > introduces new GIMPLE_QUATERNARY_RHS gassignments. For now, the VEC_COND_EXPR > remains > and is only valid in GENERIC and gimplifier will take care of the > corresponding transition. > > The patch is a prototype and missing bits are: > - folding support addition for GIMPLE_QUATERNARY_RHS is missing > - fancy tcc_comparison expressions like LTGT_EXPR, UNORDERED_EXPR, > ORDERED_EXPR, > UNLT_EXPR and others are not supported right now > - comments are missing for various functions added > > Apart from that I was able to bootstrap and run tests with a quite small > fallout. > Thoughts? > Martin
I think this is going in the wrong direction. There are some targets that can only handle VEC_COND_EXPRs well if we know the associated condition, and others where a compare-and-VEC_COND_EXPR will always be two operations. In that situation, it seems like the native gimple representation should be the simpler representation rather than the more complex one. That way the comparisons can be optimised independently of any VEC_COND_EXPRs on targets that benefit from that. So IMO it would be better to use three-operand VEC_COND_EXPRs with no embedded conditions as the preferred gimple representation and have internal functions for the fused operations that some targets prefer. This means that using fused operations is "just" an instruction selection decision rather than hard-coded throughout gimple. (And that fits in well with the idea of doing more instruction selection in gimple.) Thanks, Richard
