From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18688 invoked by alias); 23 Mar 2011 14:28:35 -0000 Received: (qmail 18654 invoked by uid 22791); 23 Mar 2011 14:28:30 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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:28:20 +0000 Received: by wyb40 with SMTP id 40so7978797wyb.20 for ; Wed, 23 Mar 2011 07:28:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.202.11 with SMTP id fc11mr6497846wbb.131.1300890497855; Wed, 23 Mar 2011 07:28:17 -0700 (PDT) Received: by 10.227.64.142 with HTTP; Wed, 23 Mar 2011 07:28:17 -0700 (PDT) In-Reply-To: References: <87k4frlz5c.fsf@firetop.home> Date: Wed, 23 Mar 2011 14:28:00 -0000 Message-ID: Subject: Re: RFC: Representing vector lane load/store operations From: Richard Guenther To: Richard Guenther , gcc@gcc.gnu.org, richard.sandiford@linaro.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00352.txt.bz2 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. =A0E.g. I'd like: >>> >>> typedef struct int8x16x4_t >>> { >>> =A0int8x16_t val[4]; >>> } int8x16x4_t; >>> >>> to have non-BLKmode as well. =A0arm_neon.h uses this type of structure >>> to represent compounds vectors. =A0But once the type is defined (with N= eon >>> support enabled), there's nothing to stop someone using the type >>> (not the intrinsics) in a function that has Neon disabled. =A0We mustn't >>> use the special mode in such cases, because there aren't enough GPRs to >>> store it. =A0It should be treated as BLKmode instead. =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. =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: > > =A0 array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size) > > which would return true if ELEMTYPE[SIZE] should use non-BLKmode where > possible. =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): > > =A0 =A0 =A0 =A0 =A0 =A0/* One-element arrays get the component type's mod= e. =A0*/ > =A0 =A0 =A0 =A0 =A0 =A0if (simple_cst_equal (TYPE_SIZE (type), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TYPE_S= IZE (TREE_TYPE (type)))) > =A0 =A0 =A0 =A0 =A0 =A0 =A0SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (typ= e))); > =A0 =A0 =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0SET_TYPE_MODE (type, mode_for_size_tree (TYPE_= SIZE (type), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MODE_INT, 1)); > > This would have the "advantage" (as I see it) of working with the > generic vector extensions too. =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? I'm confused. 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?). > We still make generic vectors available when there's no underlying > hardware support, so I'd have expected these 3-element-array-of-vector > types to be available too. =A0That's why I prefer the idea of making the > mode conditional, as for vector types, rather than rejecting uses of > the type outright. > > But from this: > >> I'd say if somebody writes >> >> v4sf float_vec; >> >> void __attribute__((target("no-sse"))) >> foo (void) >> { >> =A0 float_vec +=3D float_vec; >> } >> >> he deserves to get a diagnostic. =A0Thus, even for global decls I think = we >> can reject such uses. =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. =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. I realize this is all a bit tricky and probably nobody properly designed the target attribute stuff with all these details in mind. But now we have to live with it ... :( >> And I still think that only changing DECL_MODEs based on >> target attributes and not TYPE_MODEs is appealing ;) > > Understood. =A0I just think that, if we do that, we really should > get rid of TYPE_MODE (as a global property) as well, otherwise there'd > be even more chaos than there is now. =A0And that sounds like it could > be several months' work in itself. True. But I like the idea of TYPE_MODE becoming even more "dynamic" even less. 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 ... Richard.