This is the mail archive of the
mailing list for the GCC project.
Re: generic vectors: how should they work?
On Thu, Sep 02, 2004 at 03:09:42PM +0200, Paolo Bonzini wrote:
> >Paolo> My answer is "by reference. When, and if, they will be supported
> >by Paolo> hardware, there will be an appropriate -mabi= switch that may
> >change Paolo> this rule."
> rth's answer is more precise and appropriate. Of course I agree with
> him -- pending the introduction of new special ABI conventions for wide
> vectors, if hardware starts supporting them.
> Note that all backends but rs6000 have no problems with wide vector
> types: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00379.html includes
> a survey of that.
> rs6000 does not know about non-aggregate types of BLKmode: in rs6000.c,
> aggregates are passed in memory if bigger than 8 bytes, but vectors are not.
> >If the target includes a SIMD unit with SF support narrower than
> >the requested width, we probably want to emulate v8sf as a pair of v4sf
> >and emulate v16sf as four v4sf.
> While we do that at the arithmetic level, if the vectors are big enough
> to be BLKmode the values will always be stored in memory and never in
> several registers.
> >Are you trying to create a portable set of SIMD types or generic
> I don't understand this comment. I see SIMD types as a synonym of
> vectors. "Portable vectors", "generic vectors", "portable SIMD types",
> "generic SIMD types" seem all synonyms to me.
Here's a question that probably shows the extent of my ignorance: could
the back end determine the type for a specific generic vector that could
be quite different on powerpc, x86, or mips hardware, or on hardware
with no vector support? The same generic vector type might be
a hardware SIMD type
a synthetic SIMD type (constructed of multiple hardware SIMD types)
an array of the vector's base type
an array of hardware SIMD types
an array of synthetic SIMD types
a struct with members of the vector's base type
a struct with members of hardware SIMD types
Information about generic vectors in the GCC Manual should not depend
on how they are implemented on various platforms, although the
implementation details should be covered in the internals manual. There
should be a default way to implement generic vectors, particularly for
argument passing, with anything else covered in platform-specific ABIs.