From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 57625385828D; Tue, 12 Sep 2023 16:27:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 57625385828D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694536033; bh=8XTR+D++T2uuV64Je4qSGfLGLMWTWQTx0WuZPNmUbR8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ERxsC4QVCv5aeapqqQaIsMLzhUu3vYGktWI+iPUJq+am9QX6mXLzUgdXmufn6+7N7 T9WQDXz4bXF21WNphTC0g4zsrGtdMc41fq5sX1O+8ZG96P+8AdNy1QRx9qt3cEojHH QdtCIXUjq8+dXNnro0az8TCfILKj+bacKo2/6svo= 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: Tue, 12 Sep 2023 16:27:12 +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 #28 from JuzheZhong --- (In reply to JuzheZhong from comment #27) > (In reply to rsandifo@gcc.gnu.org from comment #26) > > 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. > >=20 > > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all argume= nts > > > type are compatible for COND_LEN_xxx in the future (Currently, it's o= bviously > > > not checking this). Then, it will cause ICE. > >=20 > > 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: > >=20 > > (cond_len all-false a b c len bias) > >=20 > > 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. > >=20 > > 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. >=20 > Thanks Richard a lot. >=20 > But I don't think we need to worry about the fold COND_LEN into > the ELSE_VALUE. >=20 > Let's back to the previous comments you gave for COND_LEN_xxx: > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html >=20 > Following your suggestions, I support cond_len_xxx by following your (1): >=20 > (1) RVV implements cond_* optabs as expanders. RVV therefore supports > both IFN_COND_ADD and IFN_COND_LEN_ADD. No dummy length arguments > are needed at the gimple level. >=20 > I use this approach to support COND_LEN_xxx since last time you have > mentioned > we will need more work in GIMPLE FOLD and other things. >=20 > To simplify the implementation of COND_LEN_xxx. We support both COND_XXX = and > COND_LEN_XXX in RISC-V backend.=20 >=20 > We don't have COND_LEN_xxx with dummy length (All dummy length case will = go > back to COND_XXX). So we forbid the case that FOLD COND_LEN_xxx into ELSE > value since COND_LEN_xxx is built always with a meaning length. >=20 > The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion, > meaning > FOLD cond_len_mult + cond_len_add into =3D=3D> cond_len_fma. That's what = I am > worry about. But currently it works fine (I have tests to test that). Moreover, Maybe we will need to worry about COND_XXX into ELSE_VALUE if I return scalar 0 in the else targethook. However, for RVV, we always use COND_LEN_xxx in the loop vectorizer which m= ay build with the argument from the ELSE_VALUE targethook. The only situation we will use COND_XXX is the UNCOND_OP + VEC_COND_EXPR -> COND_XXX in match.pd which always has a real ELSE VALUE. After these analysis, it seems that there is no risks? Not sure whether I am correct or not.=