Re: Calling conventions for vector types on SPARC

["Paolo Bonzini" <bonzini at gnu dot org>]

> > Btw, one the vector modes used by VIS on SPARC is V4QI ("pixels").  Would
> > anyone object to adding to the C family of front-ends a builtin type for
> > this mode?  Currently the compiler issues:
> > t.c:1: error: no data type for mode `V4QI'

I have a patch for this that I will send as soon as the copyright is sorted
out (I already mailed it back to Boston).  My queue consts of about 15 patches
and 3000 lines of code. :-)  It is not hard anyway to redo it -- it will take
you probably less than half an hour, just look everywhere for V4SI and add the
V4QI case.

> First, I would like to deprecate the use of __attribute__((mode(X)))
> for the creation of vectors.  Much better, IMO, is to use
> __attribute__((vector_size(N))), and pull the base mode from the
> base type.

I agree.

> Second, I would like to move all of the vector modes to the target's
> modes.def file.  This will reduce the combinatorics to just the modes
> supported by the target.

I disagree.  I have a patch, for example, which implements parallelized add
and subtraction.  On lno branch it should be able to convert on all machines

restrict char *a, *b, *c;
for (i = 0; i < N; i++)
  a[i] = b[i] + c[i];

to something like (after peeling the first N%4 iterations)

restrict int *va = a, *vb = b, *vc = c;
for (i = 0; i < N%4; i++)
  va[i] = (vb[i] & 0x7f7f7f7f) + (vc[i] & 0x7f7f7f7f)) ^
        ((vb[i] ^ vc[i]) & 0x80808080);

or even 8 bytes at a time on Alpha.  This is 8 instruction instead of 12 (for
32-bit machines) or 24 (for 64-bit machines), since the large constants can be
hoisted out of the loop.  One or two month ago you supported this idea on
gcc-patches, however, it relies on the availability of vector types beyond
those supported by the machine (and V4QI would be a very good candidate for
32-bit machines).  Logical operators are already optimized this way.

> Third, we shouldn't bother pre-creating the vector types.  We should
> create them on demand in response to the vector_size attribute.

I also agree with this.

Paolo