Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Jun 03, 2020 at 08:38:04PM +0200, Richard Biener wrote:
> On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote:
> >> >>   mask = vec_cmp of the comparison
> >> >>   true_masked = true_op & mask;
> >> >>   false_masked = false_op & ~mask;
> >> >>   result = true_masked | false_masked;
> >> >> 
> >> >> but I believe this would be dead code never triggered.
> >> >
> >> >But that would be the generic code as well?  Is that not useful to
> >have
> >> >in any case?
> >> 
> >> Sure. If you remove the vcond patterns from your port the vectorizer
> >will do this transparently for you. So if you do not actually have a
> >more clever way of representing this in the ISA there's no point of the
> >vcond patterns. (though I think the vec_cmp ones didn't originally
> >exist) 
> >
> >So why can the expander not just do that whenever the patterns FAIL as
> >well?
> 
> It could but all the vectorizer costing assumed it goes the 'cheaper' way. So this is kind of a sanity check. And what when vec_cmp expansion fails as well? Resort to scalar soft FP support as ultimate fallback? That sounds very wrong as a auto vectorization result... 

Yeah, but that is specific to the vectoriser, not something that the
RTL expander should have to deal with.  A big impedance mismatch there.

> >> The point is the vectorizer relies on a optab query for querying
> >backend support and power claims vcond support here. If you then FAIL
> >you have lied. (not in your interpretation of the pattern docs but in
> >the implementations since introduction of vcond named patterns) 
> >
> >Almost all RTL patterns are allowed to FAIL, and that is a very good
> >thing.  If the vectoriser does not allow that, *it* is buggy.
> 
> Your opinion. Please suggest a better way to query target vector capabilities. 

Again, that is what RTL does.  If the vectoriser has extra considerations
or requirements, it perhaps should use some more conditions than just
"this pattern exists"?  Maybe this can be done via the optabs, dunno.

I have no good idea how to query things better -- I don't work in the
vectorisers much at all -- but this should not constrain the target
instruction support that much (it makes no good sense to have to have
two separate patterns for things, one for the vectorisers, one for the
builtins and everything else).

Thanks,


Segher