From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1513B385C6DC; Fri, 21 Jul 2023 12:47:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1513B385C6DC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1689943650; bh=WhSrB0YSiSQqoErL3GbeeEGsPoTAVWWx5AnZurch4tc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IK0O+QZz7bsvseGB5osG0lfe2xz8FxbVzJcpVMtem4C4N3mDG+pcCvF+xFN0df+ZA HukHKRrqwrITAG+XWFcD8P4Wcc+MtbASR++UiE8+nshbnhZ3m3Edl0yk+WTDRTotMl KvYPIxHu/jVoD14c+jKBunnDZTgposxHaZnIuv9w= From: "rsandifo 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:47:28 +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: rsandifo 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 #18 from rsandifo at gcc dot gnu.org --- 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 beha= viour in the C/C++ sense: Undefined values are useful because they indicate to the compiler that the program is well defined no matter what value is used. 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 w= hat values the inactive lanes of the result have. The else value can be anythi= ng without affecting the validity of the program. So if we had undef, we woul= dn't need the hook. 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 IM= O an undef second operand would be more accurate. 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 remem= ber where.) There again, a separate =E2=80=9Ccare/don't care=E2=80=9D mask mig= ht be better for VLA. ACLE provides =E2=80=9Csvundef=E2=80=9D functions that have essentially the= same semantics as LLVM's undef. So I Think it would be useful to be able to access the semantics outside of these particular IFNs.=