From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9299 invoked by alias); 29 Nov 2001 06:21:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 9270 invoked from network); 29 Nov 2001 06:21:40 -0000 Received: from unknown (HELO www.cgsoftware.com) (208.155.65.221) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 06:21:40 -0000 Received: from localhost (pool-151-203-13-15.bos.east.verizon.net [151.203.13.15]) by www.cgsoftware.com (8.9.3/8.9.3) with ESMTP id AAA12294; Thu, 29 Nov 2001 00:55:11 -0500 Date: Wed, 21 Nov 2001 13:12:00 -0000 Subject: Re: front end changes for altivec Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: Richard Henderson , Aldy Hernandez , Stan Shebs , "Joseph S. Myers" , gcc@gcc.gnu.org To: Alexandre Oliva From: Daniel Berlin In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) X-SW-Source: 2001-11/txt/msg01026.txt.bz2 On Thursday, November 29, 2001, at 12:00 AM, Alexandre Oliva wrote: > On Nov 27, 2001, Richard Henderson wrote: > >> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote: >>> why can't you have sizeof((vector int))? > >> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)? >> Um, I guess that works. > >> But what do you do with > >> vector int x = (vector int){ 1, 2, 3, 4 }; > >> when a vector is only two elements wide? > > How about requiring that variables of type vector always be arrays > with their actual number of elements explicitly specified, or inferred > from the initializer? We should be able to infer it. After, all, all our vector modes are fixed size, and all the vector extensions we are talking of supporting have fixed size registers. While on the subject of vectors I also don't quite see the need for the overloaded functions (like altivec specifies). Why can't we just say that addition of vectors (IE c=a + b where c, a, b are vectors) transforms into (set (reg:V4SF ) (plus:V4SF (reg:V4SF ) (reg:V4SF ))). This, is, after all, what the intrinsics end up generating anyway. Are we just waiting for a devectorizing pass that splits vector modes not supported by a target machine into supported vectors or non-vectors (I'm not talking trying to map onto different element sized vector/non-vectors, just smaller ones. Like 2 v2sf's for each v4sf, if v2sf was supported by the target and v4sf was not)? Or am i missing something somehow? --Dan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Alexandre Oliva Cc: Richard Henderson , Aldy Hernandez , Stan Shebs , "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: front end changes for altivec Date: Wed, 28 Nov 2001 22:21:00 -0000 Message-ID: References: X-SW-Source: 2001-11/msg01527.html Message-ID: <20011128222100.folPZ-GIp-DOEMr3YmQtgLvxqjEHqaN1V0TBcub-nDM@z> On Thursday, November 29, 2001, at 12:00 AM, Alexandre Oliva wrote: > On Nov 27, 2001, Richard Henderson wrote: > >> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote: >>> why can't you have sizeof((vector int))? > >> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)? >> Um, I guess that works. > >> But what do you do with > >> vector int x = (vector int){ 1, 2, 3, 4 }; > >> when a vector is only two elements wide? > > How about requiring that variables of type vector always be arrays > with their actual number of elements explicitly specified, or inferred > from the initializer? We should be able to infer it. After, all, all our vector modes are fixed size, and all the vector extensions we are talking of supporting have fixed size registers. While on the subject of vectors I also don't quite see the need for the overloaded functions (like altivec specifies). Why can't we just say that addition of vectors (IE c=a + b where c, a, b are vectors) transforms into (set (reg:V4SF ) (plus:V4SF (reg:V4SF ) (reg:V4SF ))). This, is, after all, what the intrinsics end up generating anyway. Are we just waiting for a devectorizing pass that splits vector modes not supported by a target machine into supported vectors or non-vectors (I'm not talking trying to map onto different element sized vector/non-vectors, just smaller ones. Like 2 v2sf's for each v4sf, if v2sf was supported by the target and v4sf was not)? Or am i missing something somehow? --Dan