On Tue, 22 Mar 2016, Richard Biener wrote:
On March 22, 2016 4:55:13 PM GMT+01:00, Marc Glisse <marc.gli...@inria.fr>
wrote:
On Tue, 22 Mar 2016, Richard Biener wrote:
This adjusts the PR70251 fix as discussed in the PR audit trail
and fixes a bug in genmatch required (bah, stupid GENERIC comparisons
in
GIMPLE operands...).
Thanks !
Hmm, the transformation is still disabled on AVX512:
! /* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0), since vector
comparisons
! return all -1 or all 0 results. */
/* ??? We could instead convert all instances of the vec_cond to
negate,
but that isn't necessarily a win on its own. */
(simplify
! (plus:c @3 (view_convert? (vec_cond:s @0 integer_each_onep@1
integer_zerop@2)))
(if (VECTOR_TYPE_P (type)
&& TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS
(TREE_TYPE (@0))
&& (TYPE_MODE (TREE_TYPE (type))
== TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)))))
! (minus @3 (view_convert (vec_cond @0 (negate @1) @2)))))
It seems that the references to @0 in the "if" should use @1 instead
(at
least the last one). I assume this test is to make sure that A has as
many
integer elements of the same size as the result of the vec_cond_expr.
It looks like that is always guaranteed by the input form and instead these are
now useless checks which were guarding the original view-convert transform.
The input form has a view_convert_expr in it, so I don't see what prevents
from arriving here with
v4df + view_convert((v8si < v8si) ? v8si : v8si)
for instance. That seems to indicate that some test is still needed, it is
just better on the second or third argument of the vec_cond_expr than on
the condition.
Or maybe you mean we could drop the view_convert_expr from the input form.
It should have been sunk in the 2 constant arguments of the vec_cond_expr
anyway (I didn't check if that really happens). That sounds good.
I'll remove them in a followup.
Richard.
Sorry for giving you an incomplete change in the PR.
--
Marc Glisse
