From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1925 invoked by alias); 23 Mar 2011 14:41:17 -0000 Received: (qmail 1828 invoked by uid 22791); 23 Mar 2011 14:41:13 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Mar 2011 14:41:05 +0000 Received: by wyb40 with SMTP id 40so7992544wyb.20 for ; Wed, 23 Mar 2011 07:41:01 -0700 (PDT) Received: by 10.216.141.225 with SMTP id g75mr6426881wej.10.1300891261191; Wed, 23 Mar 2011 07:41:01 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id s40sm235320weq.28.2011.03.23.07.40.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 07:41:00 -0700 (PDT) From: Richard Sandiford To: Richard Guenther Mail-Followup-To: Richard Guenther ,gcc@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc@gcc.gnu.org Subject: Re: RFC: Representing vector lane load/store operations References: <87k4frlz5c.fsf@firetop.home> Date: Wed, 23 Mar 2011 14:41:00 -0000 In-Reply-To: (Richard Guenther's message of "Wed, 23 Mar 2011 15:28:17 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00353.txt.bz2 Richard Guenther writes: > On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford > wrote: >> Richard Guenther writes: >>>>> For your case in question the vectorizer would create local vars with >>>>> that mode, knowing it is supported, so I don't see big problems for >>>>> that particular case. >>>> >>>> The problem is that I'd like to use this for intrinsics as well as for >>>> automatic vectorisation. =C2=A0E.g. I'd like: >>>> >>>> typedef struct int8x16x4_t >>>> { >>>> =C2=A0int8x16_t val[4]; >>>> } int8x16x4_t; >>>> >>>> to have non-BLKmode as well. =C2=A0arm_neon.h uses this type of struct= ure >>>> to represent compounds vectors. =C2=A0But once the type is defined (wi= th Neon >>>> support enabled), there's nothing to stop someone using the type >>>> (not the intrinsics) in a function that has Neon disabled. =C2=A0We mu= stn't >>>> use the special mode in such cases, because there aren't enough GPRs to >>>> store it. =C2=A0It should be treated as BLKmode instead. =C2=A0Which I= suppose >>>> is the same situation as... >>> >>> I'd use non-BLKmode for the above unconditionally. >> >> But without Neon, there aren't enough registers to store the structure. >> Any use of the Neon mode would just lead to a reload failure. =C2=A0Even= if >> we think it's not sensible to use the type without Neon, we need a better >> diagnostic than that. >> >> So I think this mode has to be conditional in exactly the way that >> vector modes are, or be subject to the same diagnostics that you >> were suggesting for 128-bit types. >> >> I was actually thinking along the lines of having a target hook such as: >> >> =C2=A0 array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT siz= e) >> >> which would return true if ELEMTYPE[SIZE] should use non-BLKmode where >> possible. =C2=A0When it returns true, we'd pass 0 rather than 1 to this >> mode_for_size_tree call (from the ARRAY_TYPE case in layout_type): >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* One-element arrays get the c= omponent type's mode. =C2=A0*/ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (simple_cst_equal (TYPE_SIZE= (type), >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TYPE_SIZE (TREE_TYPE (type)= ))) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SET_TYPE_MODE (type, TYP= E_MODE (TREE_TYPE (type))); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SET_TYPE_MODE (type, mod= e_for_size_tree (TYPE_SIZE (type), >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MODE_INT, 1)); >> >> This would have the "advantage" (as I see it) of working with the >> generic vector extensions too. =C2=A0E.g. if a user defines their own >> 3-element-array-of-vector type, they would benefit from the same >> handling as the Neon-specific intrinsics and the vectoriser-generated >> arrays. > > So the 3-element-array-of-vector type has the vector mode of a single > element? No, it has a wider, non-vector mode. At the moment, ARM uses integer modes for this, and after trying a few variations, I think that's actually the best compromise. So the uint8x16x4_t ought to have a 64-byte integer type(!), which ARM defines as XImode: INT_MODE (XI, 64); > I also don't see how a user could want to have a non-BLK mode on such > array types (consider them being part of a struct - how would that > affect argument passing and other ABI details?). The point is that we shouldn't use the mode for the ABI anyway. Even the intrinsic-defined types (like uint8x16x4_t above) should be passed in the same way as BLKmode structures would. >>> I'd say if somebody writes >>> >>> v4sf float_vec; >>> >>> void __attribute__((target("no-sse"))) >>> foo (void) >>> { >>> =C2=A0 float_vec +=3D float_vec; >>> } >>> >>> he deserves to get a diagnostic. =C2=A0Thus, even for global decls I th= ink we >>> can reject such uses. =C2=A0Complication arises whenever we do not see >>> a decl, like for >>> >>> void foo(v4sf *x) >>> { >>> } >>> >>> which we could of course reject (at function definition time) if an >>> unsupported type is used in this way. =C2=A0But the function might >>> not even dereference that pointer ... >> >> it sounds like you think there's no point supporting generic vectors >> when no underlying hardware support is available. > > Well, I meant if the user compiles with -msse, declares such a > global var (which means it gets V4SFmode and not BLKmode) > and then uses it in a function where he explicitly disables SSE > then something is wrong. If he declares a BLKmode global > then generic vector support will happily trigger and make it work. Ah, OK. I'm just not sure whether, to take a MIPS example, MIPS16 functions in a "-mno-mips16" compile should behave differently from unannotated functions in a "-mips16" compile. > If it's just three element array-of-vector types you need why not expose > it via attribute((mode(xyz))) only? You could alias that mode to BLKmode > if neon is not enabled ... I don't think that really changes anything. Getting the non-BLK mode on the array type seems like the easy part. The difficult part is dealing with the fallout when the array is defined in a Neon context and used in a non-Neon context. Richard