On Sat, Feb 15, 2014 at 12:16 AM, Matthew Fortune <matthew.fort...@imgtec.com> wrote: >> On Fri, Feb 14, 2014 at 2:17 AM, Matthew Fortune >> <matthew.fort...@imgtec.com> wrote: >> > 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. >> >> PPC and arm and AARCH64 are common targets where vectors are >> passed/return via value. The idea is simple, sometimes you have functions >> like vector float vsinf(vector float a) where you want to be faster and >> avoid a >> round trip to L1 (or even L2). These kind of functions are common for vector >> programming. That is extending the scalar versions to the vector versions. > > I suppose this cost (L1/L2) is mitigated to some extent if the base ABI were > to pass a vector in multiple GP/FP register rather than via the stack. There > would of course still be a cost to marshall the data between GP/FP and SIMD > registers. For such a support routine like vsinf I would expect it also needs > a reduced clobber set to ensure that the caller's live SIMD registers don't > need saving/restoring, such registers would normally be caller-saved. If the > routine were to clobber all SIMD registers anyway then the improvement in > argument passing seems negligible. > > Do you/anyone know of any open source projects, which have started adopting > generic vector types, and show the use of this kind of construct?
Yes glibc provides these functions on x86 now. Thanks, Andrew > > Thanks for your input. > > Matthew > >> >> Thanks, >> Andrew Pinski >> >> > >> > Thanks in advance, >> > Matthew >> >
