MIPS is currently evaluating the benefit of using SIMD registers to pass vector data by value. It is currently unclear how important it is for vector data to be passed in SIMD registers. I.e. the need for passing vector data by value in real world code is not immediately obvious. The performance advantage is therefore also unclear.
Can anyone offer insight in the rationale behind decision decisions made for other architectures ABIs? For example, the x86 and x86_64 calling convention for vector data types presumes that they will passed in SSE/AVX registers and raises warnings if passed when sse/avx support is not enabled. This is what MIPS is currently considering however there are two concerns: 1) What about the ability to create architecture/implementation independent APIs that may include vector types in the prototypes. Such APIs may be built for varying levels of hardware support to make the most of a specific architecture implementation but be called from otherwise implementation agnostic code. To support such a scenario we would need to use a common calling convention usable on all architecture variants. 2) Although vector types are not specifically covered by existing ABI definitions for MIPS we have unfortunately got a defacto standard for how to pass these by value. Vector types are simply considered to be small structures and passed as such following normal ABI rules. This is still a concern even though it is generally accepted that there is some room for change when it comes to vector data types in an existing ABI. If anyone could offer a brief history the x86 ABI with respect to vector data types that may also be interesting. One question would be whether the use of vector registers in the calling convention was only enabled by default once there was a critical mass of implementations, and therefore the default ABI was changed to start making assumptions about the availability of features like SSE and AVX. Comments from any other architecture that has had to make such changes over time would also be welcome. Thanks in advance, Matthew
