From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id BF3813858C50; Tue, 12 Sep 2023 14:53:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF3813858C50
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1694530431;
	bh=OSDZx62ZyRsyzjzSNLZLkr7o36y+uuw6z6VhX7fS8yA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=s55S2nQ1ABKu8JTKXSkoprkX0Ek2+1ruXkkztyHASQkwA2QgGPy0BUEIMAo5XXlht
	 MbWl7mkyBc4MWk8cliIZllX6n7Evzhfkh8iqTmzQ4EutQQQ5C2owPU3J0euW4xmfBC
	 uB6rKpZphshqro6B78uxo8TaknnI5m4JzEyW7AhU=
From: "juzhe.zhong at rivai dot ai" <gcc-bugzilla@gcc.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 14:53:51 +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: <bug-110751-4-MjoID3L5hK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110751-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110751-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110751

--- Comment #25 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rsandifo@gcc.gnu.org from comment #24)
> Heh, nice hack. :)  But I guess this shows that the type checking of
> internal functions isn't as strong it should be.
>=20
> IMO it's wrong to pass a scalar else value to a vector operation.
> Even if it happens to work now, it's likely to fail in the future.
> E.g. I think match.pd fold rules should be entitled to assume
> (without checking) that all data operands to a COND_* function
> have compatible types.
>=20
> If we want an undefined operand value, I think we'll need add to
> add one that specifically has that meaning.

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 obvious=
ly
not checking this). Then, it will cause ICE.

Adding undefine value will be the optimal solution.
However, it will be a big project:
1. Add undefine in tree.def
2. Add undefine in RTL representation.
3. Adjust each PASS to handle undefine value.
4. Adjust register allocation to handle undefine value.
... etc

I can image it will be long term project to support undefine.
But we want to fix this inferior codegen of RVV currently since
I have tested various benchmark, the ELSE value hurt the performance
so much so that I want to use current infrastructure GCC to fix
this issue.=