This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: front end changes for altivec
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Bernd Schmidt <bernds at redhat dot com>
- Cc: Andreas Jaeger <aj at suse dot de>, "Joseph S. Myers" <jsm28 at cam dot ac dot uk>, gcc at gcc dot gnu dot org
- Date: 27 Nov 2001 10:31:49 -0600
- Subject: Re: front end changes for altivec
- References: <Pine.LNX.4.33.0111271556520.18978-100000@host140.cambridge.redhat.com>
> > > SSE is 128 bits.
> >
> > sorry, mmx then.
> >
> > which complicates things further... with this mmx and sse and sse2, what
> > would the default be for "vector int"? mmx is 64bits (right?) and sse
> > is 128bits, so when we talk of vector int, what are we talking about.
>
> I think all these problems show clearly that the extension is poorly thought
> out and should not be included in gcc.
that's why i brought up here first, so we can talk it through and
hopefully come up with a good design that can be used across all the
different simd architectures.
re the different sizes in x86 simd (mmx/sse/sse2), we could have the
default vector sizes depend on the macro i proposed. the macro could
return different vector sizes based on TARGET_MMX/etc flags. very
simple.
and if the user specifies:
vector<2> int foo;
it can only mean V2SI in mmx if TARGET_MMX (and available) or V2SI in
sse* if TARGET_SSE* (and available).
i don't think it's that bad.
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.