From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 1BFA23959C34 for ; Wed, 27 May 2020 07:46:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1BFA23959C34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B078955D; Wed, 27 May 2020 00:46:38 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A5B4E3F6C4; Wed, 27 May 2020 00:46:37 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener , Jim Wilson , GCC Patches , Bill Schmidt , Segher Boessenkool , David Edelsohn , richard.sandiford@arm.com Cc: Jim Wilson , GCC Patches , Bill Schmidt , Segher Boessenkool , David Edelsohn Subject: Re: [PATCH 0/7] Support vector load/store with length References: <30906c0d-3b9f-e1e6-156f-c01fcf229cb9@linux.ibm.com> Date: Wed, 27 May 2020 08:46:36 +0100 In-Reply-To: (Richard Biener's message of "Wed, 27 May 2020 09:21:15 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 07:46:40 -0000 Richard Biener writes: > On Tue, 26 May 2020, Jim Wilson wrote: > >> On Tue, May 26, 2020 at 12:12 AM Richard Biener wrote: >> > From a look at the series description below you seem to add a new way >> > of doing loads for this. Did you review other ISAs (those I'm not >> > familiar with myself too much are SVE, RISC-V and GCN) in GCC whether >> > they have similar support and whether your approach can be supported >> > there? ISTR SVE must have some similar support - what's the reason >> > you do not piggy-back on that? >> >> There isn't any RISC-V Vector support in GCC yet. The RVV spec is >> still in draft and still occasionally changing in incompatible ways. >> We've done some experimenting with gcc patches, but all we have are >> intrinsics. We haven't implemented any auto vectorization support, so >> we haven't defined tree representations for anything yet, other than >> the types we need for intrinsics support. But if it looks OK for SVE >> then it probably will be OK for RVV. > > Btw, I'm specifically looking for other load/store with length > implementations and as to whether they agree on taking bytes for > the length rather than, for example the number of lanes. I guess > exposing this detail on GIMPLE can help IV selection but if we'd > ever get a differing semantics ISA we'd have to add another set > of IFNs, so maybe the PPC ones should be named in a more specific > way like _WITH_BYTES or _BYTES or _WITH_BYTE_LENGTH or so to > allow _WITH_LANES? Maybe that detail is another thing that a cookie could hide. We'd then potentially need one IFN per approach to calculating the length parameter (bytes vs. elements, self-capping vs. explicit capping, etc.), but it would only be one IFN per approach, rather than the combinatorial explosion we'd get from one IFN per approach*load/store-kind. It doesn't make much difference when we only have one LOAD and one STORE per approach. But I imagine this will be useful for MVE, and there we'll want extending loads, truncating stores, gathers and scatters too. Thanks, Richard