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 C1F953856DE2; Mon,  6 Nov 2023 10:44:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1F953856DE2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1699267481;
	bh=dW/f4qV1OJNqf5IYP10swB87Ihd2DpUclk1VWSOmqDM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ZBVcDVLJg7aVgs/zYvpEbOrjEfwLw+aXFrD1iUsGSNcM34P8NbyQ+jr8Lp3CCtkYS
	 o30k/W81UBwpoGMrnb4dQa1UaqtyFVoY6uL0E/0x4eLq5MJxnG+3Sm7SvS3JMA/Vou
	 VW0FPpIY1zLeWl8RNfDCF1GERoh40KVjoXJjQh3g=
From: "juzhe.zhong at rivai dot ai" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111720] RISC-V: Ugly codegen in RVV
Date: Mon, 06 Nov 2023 10:44:41 +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: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juzhe.zhong at rivai dot ai
X-Bugzilla-Status: NEW
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-111720-4-rYKUvcgyYi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111720-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111720-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=3D111720

--- Comment #29 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #28)
> I tried to look up the requirements of __riscv_vle8_v_u8m2 in the vector
> intrinsic specs but besides listing all those intrinsics the spec doesn't
> contain _any_ documentation?  The 2nd arg is named 'vl' which I interpret
> as vector length so that's so difficult for this intrinsic?  Why isn't it
> just even a plain load?  I read the specified 'vl' isn't exact but the
> intrinsics are still strongly typed, so a VLA typed gimple load should ma=
tch
> here?  And there should be a way to constrain the implementation somehow
> since 'arr' has limited size.  Is the implementation constrained to use a
> vector length <=3D the specified 'vl'?

Yes. 'vl' is vector length.
The thing is that multiple types of intrinsics:

__riscv_vle8_v_u8m2
__riscv_vle8_v_u8m2_tu
__riscv_vle8_v_u8m2_tumu
__riscv_vle8_v_u8m2_mu

all of them will update elements index < vl.
But for index >=3D vl elements, we have __riscv_vle8_v_u8m2 which don't care
those
value, so they can be any value.

Wheras __riscv_vle8_v_u8m2_tu need index >=3D vl to be original old value.=