This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: generic vectors: how should they work?


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
vectors?

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.


Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]