From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24049 invoked by alias); 14 Feb 2014 10:17:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24035 invoked by uid 89); 14 Feb 2014 10:17:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: multi.imgtec.com Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 14 Feb 2014 10:17:55 +0000 From: Matthew Fortune To: "gcc@gcc.gnu.org" CC: "H.J. Lu (hjl.tools@gmail.com)" Subject: [RFC] Rationale for passing vectors by value in SIMD registers Date: Fri, 14 Feb 2014 10:17:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B023534A1937@LEMAIL01.le.imgtec.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2014_02_14_10_17_53 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00199.txt.bz2 MIPS is currently evaluating the benefit of using SIMD registers to pass ve= ctor 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 adv= antage is therefore also unclear. Can anyone offer insight in the rationale behind decision decisions made fo= r other architectures ABIs? For example, the x86 and x86_64 calling convent= ion for vector data types presumes that they will passed in SSE/AVX registe= rs 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 bui= lt for varying levels of hardware support to make the most of a specific ar= chitecture implementation but be called from otherwise implementation agnos= tic 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 defin= itions for MIPS we have unfortunately got a defacto standard for how to pas= s 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 eve= n though it is generally accepted that there is some room for change when i= t comes to vector data types in an existing ABI. If anyone could offer a brief history the x86 ABI with respect to vector da= ta types that may also be interesting. One question would be whether the us= e of vector registers in the calling convention was only enabled by default= once there was a critical mass of implementations, and therefore the defau= lt ABI was changed to start making assumptions about the availability of fe= atures 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