From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30340 invoked by alias); 28 Nov 2001 00:50:54 -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 30246 invoked from network); 28 Nov 2001 00:50:48 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 00:50:48 -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 QAA13122 for ; Tue, 27 Nov 2001 16:50:33 -0800 (PST) Received: (from aldyh@localhost) by localhost.localdomain (8.11.6/8.11.6) id fAS0qtl07673; Tue, 27 Nov 2001 18:52:55 -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 To: Richard Henderson Cc: "Joseph S. Myers" , gcc@gcc.gnu.org In-Reply-To: <20011127140031.E30114@redhat.com> References: <1006874643.5176.8.camel@litecycle.cc.andrews.edu> <20011127132756.A30114@redhat.com> <1006898082.5178.41.camel@litecycle.cc.andrews.edu> <20011127140031.E30114@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.2 (Preview Release) Date: Mon, 19 Nov 2001 15:25:00 -0000 Message-Id: <1006908775.5178.45.camel@litecycle.cc.andrews.edu> Mime-Version: 1.0 X-SW-Source: 2001-11/txt/msg00928.txt.bz2 On Tue, 2001-11-27 at 16:00, Richard Henderson wrote: > On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote: > > 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. > > How about __vector_size__(16) then? > > > and then have a default for the given backend+target_switches... > > Absolutely not. No machine dependant defaults. You can't take > that source to another machine. can anyone think of any way to get: vector int foo; /* v4si */ vector short bar; /* v2hi */ vector char hot; /* v16qi */ etc working for altivec in a target independent manner? if not, it pretty much looks like we need separate non-fsf patches to get this to work. > > > r~ -- 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 To: Richard Henderson Cc: "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: front end changes for altivec Date: Tue, 27 Nov 2001 16:50:00 -0000 Message-ID: <1006908775.5178.45.camel@litecycle.cc.andrews.edu> References: <1006874643.5176.8.camel@litecycle.cc.andrews.edu> <20011127132756.A30114@redhat.com> <1006898082.5178.41.camel@litecycle.cc.andrews.edu> <20011127140031.E30114@redhat.com> X-SW-Source: 2001-11/msg01429.html Message-ID: <20011127165000.-i3mhruVKMvJqpvqyyZDB4g7MqFTZ-ndiE7XFRAmSkM@z> On Tue, 2001-11-27 at 16:00, Richard Henderson wrote: > On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote: > > 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. > > How about __vector_size__(16) then? > > > and then have a default for the given backend+target_switches... > > Absolutely not. No machine dependant defaults. You can't take > that source to another machine. can anyone think of any way to get: vector int foo; /* v4si */ vector short bar; /* v2hi */ vector char hot; /* v16qi */ etc working for altivec in a target independent manner? if not, it pretty much looks like we need separate non-fsf patches to get this to work. > > > r~ -- Aldy Hernandez E-mail: aldyh@redhat.com Professional Gypsy Red Hat, Inc.