From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-41769-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21670 invoked by alias); 27 Nov 2001 21:52:23 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 21627 invoked from network); 27 Nov 2001 21:52:18 -0000
Received: from unknown (HELO cygnus.com) (205.180.230.5)
  by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 21:52:18 -0000
Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA20268
	for <gcc@gcc.gnu.org>; Tue, 27 Nov 2001 13:52:16 -0800 (PST)
Received: (from aldyh@localhost)
	by localhost.localdomain (8.11.6/8.11.6) id fARLsgL07474;
	Tue, 27 Nov 2001 15:54:42 -0600
X-Authentication-Warning: localhost.localdomain: aldyh set sender to aldyh@redhat.com using -f
Subject: Re: front end changes for altivec
From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Henderson <rth@redhat.com>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, gcc@gcc.gnu.org
In-Reply-To: <20011127132756.A30114@redhat.com>
References: 
	<Pine.LNX.4.33.0111270053270.4999-100000@kern.srcf.societies.cam.ac.uk>
	<1006874643.5176.8.camel@litecycle.cc.andrews.edu> 
	<20011127132756.A30114@redhat.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.99.2 (Preview Release)
Date: Mon, 19 Nov 2001 08:35:00 -0000
Message-Id: <1006898082.5178.41.camel@litecycle.cc.andrews.edu>
Mime-Version: 1.0
X-SW-Source: 2001-11/txt/msg00888.txt.bz2


> I prefer
> 
> 	int foo __attribute__((vector(4)));
> 
> which, iirc, also works as a prefix,
> 
> 	__attribute__((vector(4))) int foo;
> 
> which, with appropriate cpp magic in <altivec.h> becomes
> 
> #define __vector  __attribute__((__vector__(4)))
> 
> 	__vector int foo;

not good, because we have "vector int" (V4SI), "vector short" (V8HI),
"vector char" (V16QI), etc.  we can't just define "__vector" to expand
to a given vector size because that depends on the type being vectored.

i still prefer :):

	__vector(4) int foo;

and then have a default for the given backend+target_switches:

	__vector int foo;

a clean implementation IMO.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Henderson <rth@redhat.com>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, gcc@gcc.gnu.org
Subject: Re: front end changes for altivec
Date: Tue, 27 Nov 2001 13:52:00 -0000
Message-ID: <1006898082.5178.41.camel@litecycle.cc.andrews.edu>
References: <Pine.LNX.4.33.0111270053270.4999-100000@kern.srcf.societies.cam.ac.uk> <1006874643.5176.8.camel@litecycle.cc.andrews.edu> <20011127132756.A30114@redhat.com>
X-SW-Source: 2001-11/msg01389.html
Message-ID: <20011127135200.J1BnvHxl2eZuQc7Fd_CeQiZitCl1AihvHBxw_1c-bwU@z>

> I prefer
> 
> 	int foo __attribute__((vector(4)));
> 
> which, iirc, also works as a prefix,
> 
> 	__attribute__((vector(4))) int foo;
> 
> which, with appropriate cpp magic in <altivec.h> becomes
> 
> #define __vector  __attribute__((__vector__(4)))
> 
> 	__vector int foo;

not good, because we have "vector int" (V4SI), "vector short" (V8HI),
"vector char" (V16QI), etc.  we can't just define "__vector" to expand
to a given vector size because that depends on the type being vectored.

i still prefer :):

	__vector(4) int foo;

and then have a default for the given backend+target_switches:

	__vector int foo;

a clean implementation IMO.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.