[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port

["juzhe.zhong at rivai dot ai" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rguenther@suse.de from comment #6)
> On Tue, 12 Sep 2023, juzhe.zhong at rivai dot ai wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
> > 
> > --- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > Oh. I see.
> > 
> > 
> > (define_expand "@vcond_mask_<mode><mode>"
> >   [(match_operand:VB 0 "register_operand")
> >    (match_operand:VB 3 "register_operand")
> >    (match_operand:VB 1 "nonmemory_operand")
> >    (match_operand:VB 2 "register_operand")]
> >   "TARGET_VECTOR"
> >   {
> >    printf ("vcond_mask\n");
> >   })
> > 
> > I implemented this pattern which can address this issue....
> > 
> > Note that VB is VECTR_BOOL...
> > 
> > So, this is a more reasonable way to do. Is that right?
> 
> Ah, I suppose ISEL could special-case VECTOR_BOOLEAN_P COND_EXPR
> to expand to bitwise ops - it already does this, but only for
> non-vector-mode masks:
> 
>   /* Lower mask typed, non-vector mode VEC_COND_EXPRs to bitwise 
> operations.
>      Those can end up generated by folding and at least for integer mode 
> masks
>      we cannot expect vcond expanders to exist.  We lower a ? b : c
>      to (b & a) | (c & ~a).  */
>   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (lhs))
>       && !VECTOR_MODE_P (mode))
>     {
>       gcc_assert (types_compatible_p (TREE_TYPE (op0), TREE_TYPE (op1)));
>       gimple_seq stmts = NULL;
>       tree type = TREE_TYPE (lhs);
>       location_t loc = gimple_location (stmt);
>       tree tem0 = gimple_build (&stmts, loc, BIT_AND_EXPR, type, op1, 
> op0);
>       tree tem1 = gimple_build (&stmts, loc, BIT_NOT_EXPR, type, op0);
>       tree tem2 = gimple_build (&stmts, loc, BIT_AND_EXPR, type, op2, 
> tem1);
>       tree tem3 = gimple_build (&stmts, loc, BIT_IOR_EXPR, type, tem0, 
> tem2);
>       gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
>       return gimple_build_assign (lhs, tem3);
>     }
> 
> that could be a viable expansion strathegy when the rest fails,
> but as you can see we need four stmts for this.  If you can
> think of a smarter, maybe even single-instruction, way for riscv
> then yes, handling the above pattern looks good.
> 
> I wonder whether SVE/GCN have those.

I have supported this pattern but also need 4 instructions:

(define_expand "@vcond_mask_<mode><mode>"
  [(match_operand:VB 0 "register_operand")
   (match_operand:VB 1 "register_operand")
   (match_operand:VB 2 "register_operand")
   (match_operand:VB 3 "register_operand")]
  "TARGET_VECTOR"
  {
    /* mask1 = operands[3] & operands[1].  */
    rtx mask1 = expand_binop (<MODE>mode, and_optab, operands[1],
                              operands[3], NULL_RTX, 0,
                              OPTAB_DIRECT);
    /* mask2 = ~operands[3] & operands[2].  */
    rtx inverse = expand_unop (<MODE>mode, one_cmpl_optab, operands[3],
                               NULL_RTX,
                               OPTAB_DIRECT);
    rtx mask2 = expand_binop (<MODE>mode, and_optab, operands[2],
                              inverse, NULL_RTX, 0,
                              OPTAB_DIRECT);
    /* result = mask1 | mask2.  */
    rtx result = expand_binop (<MODE>mode, ior_optab, mask1,
                               mask2, NULL_RTX, 0,
                               OPTAB_DIRECT);
    emit_move_insn (operands[0], result);
    DONE;
  })