This is the mail archive of the
mailing list for the GCC project.
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
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.