From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A55263858C2C; Tue, 12 Sep 2023 15:59:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A55263858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694534357; bh=E4aO0BscVnEQ6SSjfai5gB7Zk18xsntJ2Fcku4QxmfY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=d1bXik2il6b09R/LeeCBrmqQdPN8U2EGnA/mIqS7xA6K3IY9u1AaMWXIYKrOisDen fvOs862D/BeoAzVbAbFHgVZZNsymJlALwW/ZJk1qDaTGPU3Nh89QX70BlCFzTPWOKf hNCT4MjdZ0+oGZHteFWQuTNf70UWqvGQ2NZG0nC4= 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: Tue, 12 Sep 2023 15:59:17 +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 #26 from rsandifo at gcc dot gnu.org --- But this is how technical debt builds up. We'd be making a change that doesn't match the type system, and that we know to be wrong in principle. And we'd be making it with no realistic prospect that it will be cleaned up later. > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments > type are compatible for COND_LEN_xxx in the future (Currently, it's obvio= usly > not checking this). Then, it will cause ICE. Yeah. But like I say, I don't think that's the most worrying scenario. For me the most worrying scenario is that a match.pd fold will say that: (cond_len all-false a b c len bias) folds to c without checking whether c is compatible with the return type. And IMO it shouldn't need to check that the type is compatible. If a rule like that triggers after this patch goes in, the pressure will be to continue to support the hack and add workarounds for it.=