From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29529 invoked by alias); 23 Mar 2011 11:52:59 -0000 Received: (qmail 29516 invoked by uid 22791); 23 Mar 2011 11:52:57 -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 11:52:50 +0000 Received: by wyb40 with SMTP id 40so7827925wyb.20 for ; Wed, 23 Mar 2011 04:52:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.61.146 with SMTP id t18mr6337385wbh.189.1300881168630; Wed, 23 Mar 2011 04:52:48 -0700 (PDT) Received: by 10.227.64.142 with HTTP; Wed, 23 Mar 2011 04:52:48 -0700 (PDT) In-Reply-To: References: <87k4frlz5c.fsf@firetop.home> Date: Wed, 23 Mar 2011 11:52: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/msg00345.txt.bz2 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. =A0Be prepared >> for some surprises during RTL expansion though ;) > > OK. =A0It's there I'd like to start, specifically with: > > =A0These arrays of vectors would still need to have a non-BLK mode, > =A0so that they can be stored in _rtl_ registers. =A0But we need that any= way > =A0for ARM's arm_neon.h; the code that today's GCC produces for the intri= nsic > =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. =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. =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: > > =A0#define TYPE_MODE(NODE) \ > =A0 =A0(TREE_CODE (TYPE_CHECK (NODE)) =3D=3D VECTOR_TYPE \ > =A0 =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. :-) =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. Richard. > Richard >