From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27153 invoked by alias); 28 Nov 2001 01:40:18 -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 27130 invoked from network); 28 Nov 2001 01:40:17 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 01:40:17 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id fAS1eGX21966 for ; Tue, 27 Nov 2001 17:40:16 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 27 Nov 2001 17:40:12 -0800 Received: from johada (johada.apple.com [17.202.41.77]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id fAS1eCh14327; Tue, 27 Nov 2001 17:40:12 -0800 (PST) Date: Tue, 20 Nov 2001 01:05: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 v472) Cc: Dale Johannesen , Richard Henderson , "Joseph S. Myers" , gcc@gcc.gnu.org To: Aldy Hernandez From: Dale Johannesen In-Reply-To: <1006910794.5178.61.camel@litecycle.cc.andrews.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) X-SW-Source: 2001-11/txt/msg00943.txt.bz2 On Tuesday, November 27, 2001, at 05:26 PM, Aldy Hernandez wrote: > > the thing is that there are builtins that expect V4SI, or V4SF, or > V16QI, etc. i guess i can have all vectors be V4SI (or vector_size(16)) > and cast them (which does nothing, but quiets the parser). > > actually, why can't we do this then: > > #define __vector __attribute__ ((mode(V4SI))) > > i still would like to have different modes for different vector types > (short, int, char). I got this working both ways and eventually let all vectors be V16QI. That removes some bloat in rs6000.md and there are somewhat fewer changes in the target-independent parts of the code (e.g. for casts). The other way is certainly more convenient for resolving those builtins, though. I come from a BE background, so to me a single mode for all 16-byte vector objects seems cleanest, but I'm sure people from FE backgrounds would disagree. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dale Johannesen To: Aldy Hernandez Cc: Dale Johannesen , Richard Henderson , "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: front end changes for altivec Date: Tue, 27 Nov 2001 17:40:00 -0000 Message-ID: References: <1006910794.5178.61.camel@litecycle.cc.andrews.edu> X-SW-Source: 2001-11/msg01444.html Message-ID: <20011127174000.5mv-m0HsG8qBWGQKUGixCIpSUE5w-_I0Jdd9SK1x90Q@z> On Tuesday, November 27, 2001, at 05:26 PM, Aldy Hernandez wrote: > > the thing is that there are builtins that expect V4SI, or V4SF, or > V16QI, etc. i guess i can have all vectors be V4SI (or vector_size(16)) > and cast them (which does nothing, but quiets the parser). > > actually, why can't we do this then: > > #define __vector __attribute__ ((mode(V4SI))) > > i still would like to have different modes for different vector types > (short, int, char). I got this working both ways and eventually let all vectors be V16QI. That removes some bloat in rs6000.md and there are somewhat fewer changes in the target-independent parts of the code (e.g. for casts). The other way is certainly more convenient for resolving those builtins, though. I come from a BE background, so to me a single mode for all 16-byte vector objects seems cleanest, but I'm sure people from FE backgrounds would disagree.