From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24678 invoked by alias); 23 Mar 2011 13:14:37 -0000 Received: (qmail 24579 invoked by uid 22791); 23 Mar 2011 13:14:33 -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 13:14:26 +0000 Received: by wyb40 with SMTP id 40so7901307wyb.20 for ; Wed, 23 Mar 2011 06:14:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.61.146 with SMTP id t18mr6411635wbh.189.1300886062904; Wed, 23 Mar 2011 06:14:22 -0700 (PDT) Received: by 10.227.64.142 with HTTP; Wed, 23 Mar 2011 06:14:22 -0700 (PDT) In-Reply-To: References: <87k4frlz5c.fsf@firetop.home> Date: Wed, 23 Mar 2011 13:14: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/msg00350.txt.bz2 On Wed, Mar 23, 2011 at 2:01 PM, Richard Sandiford wrote: > Richard Guenther writes: >>> Hmm, but if we do that, when is it correct to look at TYPE_MODE? >> >> Most of the tree passes shouldn't care about TYPE_MODE (nor >> DECL_MODE) and on RTL we shouldn't need to care about trees. > > It sounds like you think it would be better to get rid of TYPE_MODE. > I can see why that's appealing, but it also sounds very ambitious :-) > As well as all the uses in the middle-end, targets have (wrongly) tended > to use type modes to define the ABI. =A0It might be quite difficult to > untangle the whole mess now. > > Of course, that's also an argument in favour of what you say about > TYPE_MODE not changing unless we can help it... Indeed. >> 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 Neon > 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. >> > E.g. I suppose we really ought to do the same thing for 128-bit types, >> > since this: >> > >> > =A0 =A0/* TODO: This isn't correct, but as logic depends at the moment= on >> > =A0 =A0 =A0 host's instead of target's wide-integer. >> > =A0 =A0 =A0 If there is a target not supporting TImode, but has an 128= -bit >> > =A0 =A0 =A0 integer-scalar register, this target check needs to be adj= usted. */ >> > =A0 =A0if (targetm.scalar_mode_supported_p (TImode)) >> > =A0 =A0 =A0{ >> > =A0 =A0 =A0 =A0int128_integer_type_node =3D make_signed_type (128); >> > =A0 =A0 =A0 =A0int128_unsigned_type_node =3D make_unsigned_type (128); >> > =A0 =A0 =A0} >> > >> > seems to apply one value of scalar_mode_supported_p to the whole compi= lation. >> > (TImode support seems to depend on TARGET_ZARCH for s390.) >> >> Well, it depends on where int128_integer_type_node is used. =A0I think >> if the target with some settings supports TImode then we probably >> want to have that type node. =A0At the point the user declares some vars >> with it you can error out dependent on local support. At expansion >> time you'd need to check whether accesses in a given mode are >> really "possible" and dispatch to BLKmode handling if they are not. > > ...this. =A0Do you mean that we'd error for local declarations, but fall > back to BLKmode for operations on already-defined (global) declarations? > I'm just worried that might be a bit inconsistent. I'd say if somebody writes v4sf float_vec; void __attribute__((target("no-sse"))) foo (void) { float_vec +=3D float_vec; } he deserves to get a diagnostic. Thus, even for global decls I think we can reject such uses. Complication 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. But the function might not even dereference that pointer ... That said, I think for your case in question we should set possible target attribute issues aside (because we have those issues already). In that case you wouldn't need to touch TYPE_MODE at all as it would have non-BLKmode as soon as you create a vector-lane type or decl? And I still think that only changing DECL_MODEs based on target attributes and not TYPE_MODEs is appealing ;) Richard.