From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12691 invoked by alias); 23 Mar 2011 12:18:24 -0000 Received: (qmail 12568 invoked by uid 22791); 23 Mar 2011 12:18:19 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Mar 2011 12:18:10 +0000 Received: by wwj40 with SMTP id 40so9032912wwj.8 for ; Wed, 23 Mar 2011 05:18:08 -0700 (PDT) Received: by 10.216.20.141 with SMTP id p13mr7894606wep.102.1300882688228; Wed, 23 Mar 2011 05:18:08 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id a50sm3343831wer.18.2011.03.23.05.18.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 05:18:06 -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 12:18:00 -0000 In-Reply-To: (Richard Guenther's message of "Wed, 23 Mar 2011 12:52:48 +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/msg00346.txt.bz2 Richard Guenther writes: > On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford > wrote: >> Richard Guenther writes: >>> But as you have partial defs of the vector lane array the simplest >>> approach is probably to not make them a register. =C2=A0Be prepared >>> for some surprises during RTL expansion though ;) >> >> OK. =C2=A0It's there I'd like to start, specifically with: >> >> =C2=A0These arrays of vectors would still need to have a non-BLK mode, >> =C2=A0so that they can be stored in _rtl_ registers. =C2=A0But we need t= hat anyway >> =C2=A0for ARM's arm_neon.h; the code that today's GCC produces for the i= ntrinsic >> =C2=A0functions is very poor. >> >> because I'd like to fix the bad code we generate for intrinsics. >> >> Thing is, this is going to be another case where the mode of a type >> depends on the current target. =C2=A0E.g. on ARM, we don't want to use >> a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also >> available. =C2=A0Both the mode of the vector type and the mode of the >> array type will therefore depend on whether Neon is enabled. >> >> I know you don't like the way we handle TYPE_MODE for vectors: >> >> =C2=A0#define TYPE_MODE(NODE) \ >> =C2=A0 =C2=A0(TREE_CODE (TYPE_CHECK (NODE)) =3D=3D VECTOR_TYPE \ >> =C2=A0 =C2=A0 ? vector_type_mode (NODE) : (NODE)->type.mode) >> >> so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping >> up there as well. :-) =C2=A0What's the best way of handling this? > > I'd say use either DECL_MODE at the point where we decide on > expanding vars (setting it from a target hook), or simply ask such > a hook at expansion time. That should have worked for the target > atttribute stuff as well instead of dispatching in TYPE_MODE (types > are global and TYPE_MODE with the target attribute depends on > the context, but decls are local to the declaration context, so the > mode persists and is not dependent on the attribute). Might > need some surgery in places where we assume TYPE_MODE =3D=3D DECL_MODE, > but I suspect it's mostly around RTL expansion. Hmm, but if we do that, when is it correct to look at TYPE_MODE? E.g. when expanding the new __builtin_load_lanes function described earlier, it wouldn't be valid to base the target register's mode on TYPE_MODE, so I suppose we'd have to call the hook instead. And if we did revert the TYPE_MODE change for vector types, the vector optabs would need to do the same thing. Wouldn't we just end up replacing most/all uses of TYPE_MODE with calls to the hook? What would any remaining uses of TYPE_MODE actually be testing? E.g. I suppose we really ought to do the same thing for 128-bit types, since this: /* TODO: This isn't correct, but as logic depends at the moment on host's instead of target's wide-integer. If there is a target not supporting TImode, but has an 128-bit integer-scalar register, this target check needs to be adjusted. */ if (targetm.scalar_mode_supported_p (TImode)) { int128_integer_type_node =3D make_signed_type (128); int128_unsigned_type_node =3D make_unsigned_type (128); } seems to apply one value of scalar_mode_supported_p to the whole compilatio= n. (TImode support seems to depend on TARGET_ZARCH for s390.) Richard