RE: Status of SSE support in current gcc mainline

[David Korn <dkorn at pixelpower dot com>]

>-----Original Message-----
>From: Daniel Berlin [mailto:dberlin@redhat.com]
>Sent: 23 March 2001 14:50

>> Vectors are always 16 bytes on altivec.  The doc states that 'p' is a
>> pointer to a vector. 
>
>I must have misread that part, i thought it also said that sizeof(p)
>is 16, not sizeof(*p)==16.

  Well, whatever the actual case is, it's simply a thinko if the size of
a pointer-to-vector is 16 bytes, and not an essential part of the 
programming model!

>Errr, look at how, for instance, Intel does SSE programming. They have
>a few datatypes defined, a whole bunch of intrinsics, and C++ classes
>that encapsulate the intrinsics in a vector class, etc.
>
>They didn't make basic changes to the actual language to try to
>accomodate their code.

  Do you have a pointer to any docs handy?  I'd be interested to see this.
How does it work for normal C?  I'd hate to have to jump through a virtual
function pointer every time I wanted to add two vectors - then again I'm
afraid I don't know the meaning of the term 'intrinsic' - is it like a 
builtin ?

>As a result, MSVC7, Intel's reference compiler,, and
>various versions of GCC (probably not seen by most) support the
>model without any trouble(off the top of my head, i'm sure there are
>more). In fact, I can compile the same code on any of the compilers,
>
>What's better, things like the vector class that uses the intrinsics
>will use normal, non-SSE calculations if your platform doesn't support
>it (through #ifdefs).

  Are you saying that there's no direct way for the coder to control
the low level details of how the vector instructions are used?  I did
like the idea of having vector types and builtins that compile straight
down to single asm instructions.

  I am completely unfamiliar with the intel model, but ISTM that the
motorola version is something that low level, pedal-to-the-metal
performance hackers would be happier with, and the intel one is more
suited to the needs of high level number crunching and portable coding.

  You mentioned an auto-vectorizing pass in your earlier post, but I feel
that might miss the point somewhat.  Unless you've designed your dataflow
and application architecture with streaming and SIMD in mind, you're only
going to get a fraction of the benefits that the extensions could 
potentially provide.  If protability is your overwhelming consideration,
that might be a reasonable compromise, but the reason why 1GHz CPUs
run like lightning under some OSes and suck through a thin straw under
others (naming no names!) is because people assume that performance can
be left to the optimizer, rather than needing to be designed in from the
word go.  I'd be very impressed with the amount of intelligence in an
auto-vectorizing compiler that achieved anywhere near the same results as
a human being.

        DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************