https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121604

--- Comment #3 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(In reply to Jennifer Schmitz from comment #2)
> Thanks for catching this.
> Both svbrka and svbrkb produce wrong code with _m predication. Same for
> svpmov_lane with _m and a pfalse predicate.
> The problem for svbrka/b is that they get folded by the code intended to
> fold non-unary function shapes with pfalse predicate, because the inactive
> operand happens to be a pfalse in the lines I marked.
> svpmov_lane on the other hand gets folded by the code intended for unary
> shapes:
> 
> gimple *
> gimple_folder::fold_pfalse ()
> {
>   if (pred == PRED_none)
>     return nullptr;
>   tree arg0 = gimple_call_arg (call, 0);
>   if (pred == PRED_m)
>     {
>       /* Unary function shapes with _m predication are folded to the
>        inactive vector (arg0), while other function shapes are folded
>        to op1 (arg1).  */
>       tree arg1 = gimple_call_arg (call, 1);
>       if (is_pfalse (arg1))         // <----- svpmov_lane gets folded HERE
>       return fold_call_to (arg0); // <----- svpmov_lane gets folded HERE
>       if (is_pfalse (arg0))         // <----- svbrka/b get folded HERE
>       return fold_call_to (arg1); // <----- svbrka/b get folded HERE
>       return nullptr;
>     }
>   ...
>   return nullptr;
> }

So looking at this, ISTM that the problem (with both svbrkb and the pmov_lane
case) is really that the code uses is_pfalse as a proxy for the position of the
governing predicate.  That falls over for svbrkb because it operates
exclusively on predicates; the signature is:

svbool_t svbrkb[_b]_m (svbool_t inactive, svbool_t pg, svbool_t op);

so the code above is confused into thinking that the first operand is the
governing predicate.  For svpmov_lane, the problem is rather that there is no
governing predicate, but a non-governing predicate operand (which again is
incorrectly taken to be the GP).

ISTM it would be better if we were more explicit about the position of the GP
(if there is one).  Perhaps we can determine it from the function_shape
information?  I don't know the code well enough to say off-hand, but can try to
look into it.

Reply via email to