From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id A1EB43858402; Tue, 12 Sep 2023 12:36:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1EB43858402
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1694522192;
	bh=1EW1ARONwhHagljpV97UxsuxuCcJsxMTON6GBK7bhdk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=lKZ1KUorfCHvorf4EkV32WAAkN8B2ZNgbP8El/H2KX/zBNNAw4hP1AfiWz+qxXvVM
	 49cpLsAxuVm/IV6VMJhXmXecUO4obIi1RbNjha9fobS4ZYF/mvyhaG9TF3uhY7go5Q
	 a9GBLpXRsAfwzkNbKRy7uaishCkiSdczx1rK4emw=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
Date: Tue, 12 Sep 2023 12:36:32 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111337-4-LuZWr3xkgy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111337-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111337-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Sep 2023, juzhe.zhong at rivai dot ai wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111337
>=20
> --- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> Oh. I see.
>=20
>=20
> (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");
>   })
>=20
> I implemented this pattern which can address this issue....
>=20
> Note that VB is VECTR_BOOL...
>=20
> 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=20
operations.
     Those can end up generated by folding and at least for integer mode=20
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 =3D NULL;
      tree type =3D TREE_TYPE (lhs);
      location_t loc =3D gimple_location (stmt);
      tree tem0 =3D gimple_build (&stmts, loc, BIT_AND_EXPR, type, op1,=20
op0);
      tree tem1 =3D gimple_build (&stmts, loc, BIT_NOT_EXPR, type, op0);
      tree tem2 =3D gimple_build (&stmts, loc, BIT_AND_EXPR, type, op2,=20
tem1);
      tree tem3 =3D gimple_build (&stmts, loc, BIT_IOR_EXPR, type, tem0,=20
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.=