From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7309B385C017; Fri, 21 Jul 2023 12:53:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7309B385C017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1689943989; bh=U1LAIKrfRAFIRLM7hcQceZYbwn7twvEp4g/irG497rc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ca8UJ9iZHN9LzqMP9DlvBPeECAlyyNMFm1mHrfDFFLcuZxT88GkHdkQJNyRSMNdeY wfsoQquBCcguLuziQxank+ub8ZnpLDlLjykBD2IO7gLKGgvADBEYYS3qQ+l8W3RNxa TNO6AxmmUqyxndtGoMk1t3SIn2eRf5N+Isif1hUQ= From: "rguenth at gcc dot 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: Fri, 21 Jul 2023 12:53:08 +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: rguenth at gcc dot gnu.org 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 #19 from Richard Biener --- (In reply to rsandifo@gcc.gnu.org from comment #18) > I'd understood LLVM's undef as essentially being =E2=80=9Cunspecified=E2= =80=9D, or > =E2=80=9Cunspecified bit-pattern=E2=80=9D to quote the docs. It doesn't = indicate undefined > behaviour in the C/C++ sense: >=20 > Undefined values are useful because they indicate to the compiler that > the program is well defined no matter what value is used. >=20 > And I think that's what we want here. The reason we have > TARGET_PREFERRED_ELSE_VALUE is that the vectoriser sometimes doesn't care > what values the inactive lanes of the result have. The else value can be > anything without affecting the validity of the program. So if we had und= ef, > we wouldn't need the hook. >=20 > I think the same thing applies to a VEC_PERM_EXPR that only selects from = the > first vector. We canonicalise that by duplicating the vector input, but = IMO > an undef second operand would be more accurate. >=20 > An undef value would also allow us to represent =E2=80=9Cdon't care=E2=80= =9D indices in a > permute index vector, such as -1 in a __builtin_shuffle call. (There were > times when I wanted the same thing in the vectoriser too, but I can't > remember where.) There again, a separate =E2=80=9Ccare/don't care=E2=80= =9D mask might be > better for VLA. >=20 > ACLE provides =E2=80=9Csvundef=E2=80=9D functions that have essentially t= he same semantics > as LLVM's undef. >=20 > So I Think it would be useful to be able to access the semantics outside = of > these particular IFNs. Sure, I can kind of see the usefulness elsewhere. Just for this particular issue it doesn't seem necessary to sit down and design this when we can represent it like we do for MASK_LOAD (omit the 'else' value). As noted above we have the use-case of a not undefined 'else' value. But I agree, in theory we could drop the target hook and omit the 'else' value when we don't need any particular one. So what I want to point out is that we're fine without for MASK_LOAD so we should be fine without elsewhere as well. In other context we discussed specifying zero for MASK_LOAD masked elements so we can for example CSE better. CSE with UNDEF might be possible as well, but I'm not sure what LLVM's undef would allow and whether it's defined rigidly enough.=