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 252703858C33; Thu, 20 Jul 2023 11:28:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 252703858C33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689852510;
	bh=ziByTZJ4iSY4AqF+J7SxjsQSnNJKxQiJws0hTvMwYww=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=BkDvmAf6wZJKxx9ivaBJVYNT9XtgQ/L4KQmaAIBfB2h35xafoJa7cDX+NXV0657tq
	 CqGw26gGfbkbe5duknHHZqVxQCnlkVxXO32iAy02OxzyZy3c2IslzpQf4ZtbiTIOr6
	 NxtW8TFFjrIwBNPJHeXVx3VfB7rB0sFjQzj1+8S0=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110751] RISC-V: Suport undefined value that allows
 VSETVL PASS use TA/MA
Date: Thu, 20 Jul 2023 11:28:29 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
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-110751-4-dkYQRehebI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110751-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110751-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=3D110751

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 20 Jul 2023, kito at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110751
>=20
> --- Comment #4 from Kito Cheng <kito at gcc dot gnu.org> ---
> > OK, so TA is either merge or all-ones.
>=20
> Yes, your understand is correct, just few more detail is that can be mixi=
ng
> with either merge or all-ones.
>=20
> e.g.
>=20
> An 4 x i32 vector with mask 1 0 1 0
>=20
> Op  =3D  | a | b | c | d |
> Mask =3D | 1 | 0 | 1 | 0 |
>=20
> the result could be:
> | a | b | c | d |
> | a | all-1 | c | d |
> | a | all-1 | c | all-1 |
> | a | all-1 | c | d |
>=20
>=20
> > Not sure how you can use MA at the moment since you specify an existing=
 operand in your target hook.  As far as
> > I can see there's no value the target hook can provide that matches any
> of the implementation semantics?
>=20
> That's the key point - we don't know how to return an undefined value the=
re, we
> have intrinsic can generate undefined value, but it seems impossible to
> generate that within the hook.

Well, neither *A nor *U can be specified currently.  As said for 'merge'
we would need another operand.  And since 'unspecified' is either merge
or all-ones we can't express that either.  It's not really 'undefined'
either.

Note this also means the proposal to define a .MASK_LOAD as zeroing
masked elements is not going to work for RISC-V, instead we'd need
an explicit 'else' value there as well.

In fact we could follow .MASK_LOAD for .COND_* and simply omit
the 'else' operand for the case of 'unspecified', no?  GIMPLE would
be fine omitting it, not sure whether there's precedent for
optabs with optional operands?=