opaque vector types?

opaque vector types?

[DJ Delorie]

Is there an opaque vector type?  Something that can be assigned
to/from other vector types of the same size, without warning?

I'm working on a coprocessor which has separate SIMD arithmetic
operations for each data size, but only one SIMD logical operation for
all sizes.  I.e. there's four ADD insns (V8QI, V4HI, etc) , but only
one AND insn.  I'd like to use an opaque vector type for the AND
builtin, to avoid warnings.

Re: opaque vector types?

[Andrew Pinski]

On Tue, May 5, 2009 at 11:04 PM, DJ Delorie <dj@redhat.com> wrote:
> I'm working on a coprocessor which has separate SIMD arithmetic
> operations for each data size, but only one SIMD logical operation for
> all sizes.  I.e. there's four ADD insns (V8QI, V4HI, etc) , but only
> one AND insn.  I'd like to use an opaque vector type for the AND
> builtin, to avoid warnings.

You could do what the rs6000 back-end does for the altivec builtins
and resolve them while the parser is run (the SPU back-end does the
same thing too).  Yes there are opaque vector types, you just use
build_opaque_vector_type instead of build_vector_type.

-- Pinski

Re: opaque vector types?

[DJ Delorie]

Andrew Pinski <pinskia@gmail.com> writes:
> You could do what the rs6000 back-end does for the altivec builtins
> and resolve them while the parser is run (the SPU back-end does the
> same thing too).  Yes there are opaque vector types, you just use
> build_opaque_vector_type instead of build_vector_type.

Thanks, I'll look at those.  Any way to prototype such functions in C ?

Re: opaque vector types?

[Paolo Bonzini]

DJ Delorie wrote:
> Andrew Pinski <pinskia@gmail.com> writes:
>> You could do what the rs6000 back-end does for the altivec builtins
>> and resolve them while the parser is run (the SPU back-end does the
>> same thing too).  Yes there are opaque vector types, you just use
>> build_opaque_vector_type instead of build_vector_type.
> 
> Thanks, I'll look at those.  Any way to prototype such functions in C ?

If the opaque vector type is exported as say __v4si_opaque__ that would
be simply

extern __v4si_opaque__ my_and (__v4si_opaque__, __v4si_opaque__);

Opaque vector types are not available via attributes, but that could be
easily added.

Paolo

Re: opaque vector types?

[Michael Meissner]

On Wed, May 06, 2009 at 02:29:46AM -0400, DJ Delorie wrote:
> 
> Andrew Pinski <pinskia@gmail.com> writes:
> > You could do what the rs6000 back-end does for the altivec builtins
> > and resolve them while the parser is run (the SPU back-end does the
> > same thing too).  Yes there are opaque vector types, you just use
> > build_opaque_vector_type instead of build_vector_type.
> 
> Thanks, I'll look at those.  Any way to prototype such functions in C ?

As Andrew says the rs6000/spu have the notion of overloaded builtins.  I've
been working in this area somewhat for the power7 port, and you might want to
look at my power7-branch.

In rs6000.h it uses REGISTER_TARGET_PRAGMAS to set the
resolve_overloaded_builtin target hook:

/* Target pragma.  */
#define REGISTER_TARGET_PRAGMAS() do {				\
  c_register_pragma (0, "longcall", rs6000_pragma_longcall);	\
  targetm.resolve_overloaded_builtin = altivec_resolve_overloaded_builtin; \
} while (0)

In rs6000-c.c you have the function that tries to resolve the builtin given the
argument types:

tree
altivec_resolve_overloaded_builtin (tree fndecl, void *passed_arglist)
{
	...
}

It returns a tree of the builtin function with the appropriate types.  In the
code, there is a giant table (altivec_overloaded_builtins) that maps the
generic builtin functions to the specific ones based on the argument types.

For example, altivec has a builtin function that does absolute value for any
vector type, and internally it converts this to the appropriate builtin for
each type:

const struct altivec_builtin_types altivec_overloaded_builtins[] = {
  /* Unary AltiVec/VSX builtins.  */
  { ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V16QI,
    RS6000_BTI_V16QI, RS6000_BTI_V16QI, 0, 0 },
  { ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V8HI,
    RS6000_BTI_V8HI, RS6000_BTI_V8HI, 0, 0 },
  { ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V4SI,
    RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0, 0 },
  { ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V4SF,
    RS6000_BTI_V4SF, RS6000_BTI_V4SF, 0, 0 },
    ...
};

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com

Re: opaque vector types?

[Paul Brook]

On Wednesday 06 May 2009, DJ Delorie wrote:
> Is there an opaque vector type?  Something that can be assigned
> to/from other vector types of the same size, without warning?
>
> I'm working on a coprocessor which has separate SIMD arithmetic
> operations for each data size, but only one SIMD logical operation for
> all sizes.  I.e. there's four ADD insns (V8QI, V4HI, etc) , but only
> one AND insn.  I'd like to use an opaque vector type for the AND
> builtin, to avoid warnings.

FWIW ARM/NEON solve this by defining the full set of builtins for all types, 
and some of them (e.g. AND) happen to expand to the same machine instructions.

In practice I'd expect this actually makes writing vector code easier/safer 
because you don't loose type safety every time you use the AND builtin.

Having some of your intrinsics be type specific, and some type agnostic seems 
a somewhat strange programming model. I'd expect everything to be types, or 
everything to use opaque vectors (and select the opcode based on the actual 
argument types). The latter is problematic because C doesn't really have 
polymorphism.

Paul