https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115683
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > Richi, maybe tree optimizers can perform their optimizations with
> > vec_cmp{,u} and vcond_mask, and at the end provide the true coditional
> > vector move (that calls "vcond{,u}") as a compound operation of these two
> > operations?
> Yeah, if a target can only handle a comparison by inverting the result, then
> IMO the long-term outcome should be that the target doesn't provide that
> comparison, and that target-independent code instead does the obvious
> adjustment. At the moment (or at least, before the removal of the optabs),
> every target did this internally, and the true picture was hidden from
> gimple.
Yes. I'd like to approach this piecemail, first cleaning up the ISEL &
vectorizer mess with having to support both forms now (when) all targets
implement vec_cmp and vcond_mask.
For the case of a "min/max" instruction implementing exactly
a > b ? a : b we possibly want a separate optab - I'm not sure if there's
another target besides x86 having an instruction for this form. I just
don't have a good name for such optab, but it should have three operands,
the two values A and B and a compare RTX (for the code), comparing A op B
(order matters here). I can think of <, >, <= and >= being sensible
semantic choices? It does look awfully like vcond (but also applies to
scalar IMO), with the additional restriction of re-using the compare
operands as result operands.
