From mboxrd@z Thu Jan 1 00:00:00 1970 From: Per Bothner 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:25:00 -0000 Message-ID: <3C05D4D7.8000204@bothner.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> <3C0418B1.8B56487D@apple.com> <20011127151526.A30257@redhat.com> <1006909175.5178.51.camel@litecycle.cc.andrews.edu> <20011127170302.B30341@redhat.com> X-SW-Source: 2001-11/msg01528.html Message-ID: <20011128222500.N70Fsq_G-lUjBHZ7U8kdeY2IIbdB1ttay5llASD7fME@z> Alexandre Oliva wrote: > 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 could still support implicit iteration over vector elements for > operations such as copying, addition and subtraction, relieving the > source code from the need to worry about the exact vector size, while > still allowing code to pick into it somehow, for example: > > vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s > > vector int y[7]; > > ... > > y = x; > y = x + y; My recommendation is to define the extension as syntactic sugar for a C++ template. That has the advantage of providing a clean definition. There happens to be a standard C++ template that seems to closely match what is needed: valarray. This was specifically designed to be highly optimizable and to be mapped to vector hardware. My preference: * We provide hooks so that valarray implementations can run optimized on suitable hardware, including Altivec and MMX. * We encourage programmers who want to write efficient code to use C++ and the valarray type. They gain the benefits of making their code both portable and fast. * If we define a C "vector" extension we define in terms of the C++ valarray type. Specifically, there should be no Altivec-target-dependent functionality or optimizations that you can access from the C extension that you can't also access using the valarray template in C++. I want to encourage people to write clean portable code, not some kludge. A pre-processor that translates from Alticvec C into valarray-using C++ code would be my preference. -- --Per Bothner per@bothner.com http://www.bothner.com/per/