From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25687 invoked by alias); 29 Mar 2011 13:30:11 -0000 Received: (qmail 25668 invoked by uid 22791); 29 Mar 2011 13:30:10 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_DQ,TW_OV,TW_VD 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; Tue, 29 Mar 2011 13:30:05 +0000 Received: by wwf26 with SMTP id 26so171617wwf.8 for ; Tue, 29 Mar 2011 06:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.178.14 with SMTP id bk14mr5039721wbb.102.1301405404268; Tue, 29 Mar 2011 06:30:04 -0700 (PDT) Received: by 10.227.64.142 with HTTP; Tue, 29 Mar 2011 06:30:04 -0700 (PDT) In-Reply-To: References: <87k4frlz5c.fsf@firetop.home> Date: Tue, 29 Mar 2011 14:05: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/msg00471.txt.bz2 On Tue, Mar 29, 2011 at 2:44 PM, Richard Sandiford wrote: > Richard Sandiford writes: >> Richard Guenther writes: >>> 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. =A0If he declares a BLKmode global >>> then generic vector support will happily trigger and make it work. >> >> Ah, OK. =A0I'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? =A0You could alias that mode to BLK= mode >>> if neon is not enabled ... >> >> I don't think that really changes anything. =A0Getting the non-BLK mode >> on the array type seems like the easy part. =A0The difficult part is >> dealing with the fallout when the array is defined in a Neon context >> and used in a non-Neon context. > > As a follow-up to this, I think the current definition of TYPE_MODE > is too restrictive even for the vector case. =A0Single-element structures > get the modes of their fields, and similarly for arrays. =A0So if we modi= fy > the original 38240 testcase a bit, we still get a difference: > > ------------------------------------------------------------------------- > #if STRUCT > typedef struct { > =A0float x __attribute__ ((__vector_size__ (16), __may_alias__)); > } V; > #else > typedef float V __attribute__ ((__vector_size__ (16), __may_alias__)); > #endif > > V __attribute__((target("sse"))) f(const V *ptr) { return *ptr; } > ------------------------------------------------------------------------- > > Without -DSTRUCT, this generates the same code regardless of whether > you compile with -msse. =A0But with -DSTRUCT, you get: > > =A0 =A0 =A0 =A0movaps =A0(%rdi), %xmm0 > =A0 =A0 =A0 =A0ret > > with -msse and: > > =A0 =A0 =A0 =A0movq =A0 =A0(%rdi), %rax > =A0 =A0 =A0 =A0movq =A0 =A0%rax, -24(%rsp) > =A0 =A0 =A0 =A0movq =A0 =A08(%rdi), %rax > =A0 =A0 =A0 =A0movq =A0 =A0%rax, -16(%rsp) > =A0 =A0 =A0 =A0movdqa =A0-24(%rsp), %xmm0 > =A0 =A0 =A0 =A0ret > > with -mno-sse. > > I think your argument is that most/all uses of TYPE_MODE are a mistake. > But I still think it makes sense to say that types have a natural mode > _in a given context_, just not globally. =A0So how about replacing it with > a current_mode_of_type function? =A0That makes it obvious that TYPE_MODE = is > not a global property, and that it isn't really a simple accessor any mor= e. > We could then make it recompute the mode for all types, possibly with a > cache if that's necessary for performance reasons. Well, ok. That current_mode_of_type wouldn't make sense when for example expanding global initializers (neither would looking at TYPE_MODE). But - what's the natural mode to choose for global entities? After all we have to stick something into TYPE_MODE and DECL_MODE. But yes, changing the TYPE_MODE users over to current_mode_of_type (or rather mode_of_type_in_fn (struct function *, tree)) would be nice (and then get rid of the TYPE_MODE hack). Richard. > Richard >