From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CC5503853D22; Thu, 20 Jul 2023 12:00:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC5503853D22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1689854447; bh=new1my8QCng+dLOQePyXLmKYxbGNHU9soCsIH3BBazw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qXjDNPqqYPh4e4TWPUpn2n3N+eAbfQ099XCnwAR+Hfc8tToAxx5eGpTwTfSdK8fHg rzjqxYxZ7mkBxc4NMXrvvrhAsE0ci5SiG4tIxcZM9M9T/08DiYX5saASYHx7zV3GCL HtY8VvXi46bhe2k6f9AZoXXyaikhVt2AzhknBOZA= From: "juzhe.zhong at rivai dot ai" 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 12:00:47 +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: juzhe.zhong at rivai dot ai 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110751 --- Comment #7 from JuzheZhong --- (In reply to rguenther@suse.de from comment #5) > On Thu, 20 Jul 2023, kito at gcc dot gnu.org wrote: >=20 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110751 > >=20 > > --- Comment #4 from Kito Cheng --- > > > OK, so TA is either merge or all-ones. > >=20 > > Yes, your understand is correct, just few more detail is that can be mi= xing > > 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 existi= ng operand in your target hook. As far as > > > I can see there's no value the target hook can provide that matches a= ny > > of the implementation semantics? > >=20 > > That's the key point - we don't know how to return an undefined value t= here, we > > have intrinsic can generate undefined value, but it seems impossible to > > generate that within the hook. >=20 > 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. >=20 > 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. >=20 > 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? I am wondering whether we can build a CONST_VECTOR with metadata in the tree attribute that can be seen in the RTL level during "expand" stage. For example, can we have some like this: tree undef =3D build_zero_cst (vectype) TREE_ATTRIBUTE (undef) =3D "undefined" Then, in the expand stage, tree t =3D get_tree (rtx) if (TREE_ATTRIBUTE (t) =3D=3D =E2=80=9Cundefined=E2=80=9D) { ... } This is my immature idea. Feel free to correct me.=