From patchwork Thu Jun 28 12:30:15 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 167862 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 6DE75B6FF5 for ; Thu, 28 Jun 2012 22:30:58 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1341491458; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Date:From:To:CC:Subject:Message-ID:User-Agent: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=gUe2+IoGO60WOG1Z+2JS/xcaCtk=; b=Sz8txAMXeVIKn/Z KVKRrbE35RLVoMuTaP22aDhqVziVQQsmM0dkMC+pAlSPI5eSY9Mej2hobWvfrEGr DRP/a709IzgtlGlL4blwSl0lGxhnA1tDEo8dMc1mwd/pP1hKV+qpMIQ5aFUnwiz0 UeB7GwgKZMS34VK+si5WFXOYxbzM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Date:From:To:CC:Subject:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=jjSTiStW/kZE+tMu24EMpLXu2Cbgu3QWk/FKSrGb+L7Cho/MY1jlFqel4RdtiZ d3VYbgLH8qXpdncTjnt8wR5KGSXImvycBgbsZwSEWPGg0pZhg9Y0MN4zcdxXSTNT H/PKJ7b19hsT4EAKEjDQE6sm2q+wB0oBsSFyN1WfA1QrE=; Received: (qmail 31515 invoked by alias); 28 Jun 2012 12:30:53 -0000 Received: (qmail 31498 invoked by uid 22791); 28 Jun 2012 12:30:50 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Jun 2012 12:30:32 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SkDrj-00079H-OK from Maciej_Rozycki@mentor.com for gcc-patches@gcc.gnu.org; Thu, 28 Jun 2012 05:30:31 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 05:30:31 -0700 Received: from [172.30.1.7] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 28 Jun 2012 13:30:29 +0100 Date: Thu, 28 Jun 2012 13:30:15 +0100 From: "Maciej W. Rozycki" To: CC: Catherine Moore Subject: [PATCH] MIPS/libgcc: Add soft-fp support for SDE bare-iron targets Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hello, This change adds soft-fp support for SDE bare-iron targets. The settings have been mostly based on the version already present in glibc, except that the ABI variations have been merged into a single file and conditionalised on preprocessor macros (and the file reformatted to follow the GNU coding standard that the glibc variants don't). Only n32 has to be treated somewhat specially as it is ILP32 but its "long long" type is 64-bit with native support (using single registers rather than pairs). The rest is handled generically, based on the width of the types chosen. This has been regression tested for the mips-sde-elf target with no new failures, using the o32 and n64 ABI multilibs, with and without -msoft-float, o32 also with MIPS16 variants. There's currently no SDE runtime support for n32, however despite the unability to test I decided the configuration shouldn't be pessimised by default (by avoiding the special exception and using the 32-bit "long" type) as glibc already uses such an arrangement so it's been verified elsewhere and if a platform that supports the n32 ABI decides later on to enable soft-fp too, it will be verified in libgcc anyway. I believe this is reasonable and avoids the risk of someone chooing the "long" type by omission. Comments or questions are welcome, otherwise OK to apply? 2012-06-28 Catherine Moore Maciej W. Rozycki libgcc/ * config/mips/sfp-machine.h: New file. * config.host : Enable soft-fp. Maciej gcc-mips-softfp.diff Index: gcc-trunk-4.6/libgcc/config/mips/sfp-machine.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc-trunk-4.6/libgcc/config/mips/sfp-machine.h 2012-06-24 14:38:40.083663725 +0100 @@ -0,0 +1,101 @@ +#if defined _ABIN32 && _MIPS_SIM == _ABIN32 + +#define _FP_W_TYPE_SIZE 64 +#define _FP_W_TYPE unsigned long long +#define _FP_WS_TYPE signed long long +#define _FP_I_TYPE long long + +#else + +#define _FP_W_TYPE_SIZE _MIPS_SZLONG +#define _FP_W_TYPE unsigned long +#define _FP_WS_TYPE signed long +#define _FP_I_TYPE long + +#endif + +#if _FP_W_TYPE_SIZE < 64 + +#define _FP_MUL_MEAT_S(R, X, Y) \ + _FP_MUL_MEAT_1_wide (_FP_WFRACBITS_S, R, X, Y, umul_ppmm) +#define _FP_MUL_MEAT_D(R, X, Y) \ + _FP_MUL_MEAT_2_wide (_FP_WFRACBITS_D, R, X, Y, umul_ppmm) +#define _FP_MUL_MEAT_Q(R, X, Y) \ + _FP_MUL_MEAT_4_wide (_FP_WFRACBITS_Q, R, X, Y, umul_ppmm) + +#define _FP_DIV_MEAT_S(R, X, Y) \ + _FP_DIV_MEAT_1_udiv_norm (S, R, X, Y) +#define _FP_DIV_MEAT_D(R, X, Y) \ + _FP_DIV_MEAT_2_udiv (D, R, X, Y) +#define _FP_DIV_MEAT_Q(R, X, Y) \ + _FP_DIV_MEAT_4_udiv (Q, R, X, Y) + +#else + +#define _FP_MUL_MEAT_S(R, X, Y) \ + _FP_MUL_MEAT_1_imm (_FP_WFRACBITS_S, R, X, Y) +#define _FP_MUL_MEAT_D(R, X, Y) \ + _FP_MUL_MEAT_1_wide (_FP_WFRACBITS_D, R, X, Y, umul_ppmm) +#define _FP_MUL_MEAT_Q(R, X, Y) \ + _FP_MUL_MEAT_2_wide_3mul (_FP_WFRACBITS_Q, R, X, Y, umul_ppmm) + +#define _FP_DIV_MEAT_S(R, X, Y) \ + _FP_DIV_MEAT_1_imm (S, R, X, Y, _FP_DIV_HELP_imm) +#define _FP_DIV_MEAT_D(R, X, Y) \ + _FP_DIV_MEAT_1_udiv_norm (D, R, X, Y) +#define _FP_DIV_MEAT_Q(R, X, Y) \ + _FP_DIV_MEAT_2_udiv (Q, R, X, Y) + +#endif + +#define _FP_NANFRAC_S ((_FP_QNANBIT_S << 1) - 1) +#define _FP_NANFRAC_D ((_FP_QNANBIT_D << 1) - 1), -1 +#define _FP_NANFRAC_Q ((_FP_QNANBIT_Q << 1) - 1), -1, -1, -1 +#define _FP_NANSIGN_S 0 +#define _FP_NANSIGN_D 0 +#define _FP_NANSIGN_Q 0 + +#define _FP_KEEPNANFRACP 1 +/* From my experiments it seems X is chosen unless one of the + NaNs is sNaN, in which case the result is NANSIGN/NANFRAC. */ +#define _FP_CHOOSENAN(fs, wc, R, X, Y, OP) \ + do { \ + if ((_FP_FRAC_HIGH_RAW_##fs (X) \ + | _FP_FRAC_HIGH_RAW_##fs (Y)) & _FP_QNANBIT_##fs) \ + { \ + R##_s = _FP_NANSIGN_##fs; \ + _FP_FRAC_SET_##wc (R, _FP_NANFRAC_##fs); \ + } \ + else \ + { \ + R##_s = X##_s; \ + _FP_FRAC_COPY_##wc (R, X); \ + } \ + R##_c = FP_CLS_NAN; \ + } while (0) + +#define FP_EX_INVALID (1 << 4) +#define FP_EX_DIVZERO (1 << 3) +#define FP_EX_OVERFLOW (1 << 2) +#define FP_EX_UNDERFLOW (1 << 1) +#define FP_EX_INEXACT (1 << 0) + +#define __LITTLE_ENDIAN 1234 +#define __BIG_ENDIAN 4321 + +#if defined MIPS_EB || defined __MIPSEB__ || defined MIPSEB || defined _MIPSEB +# if defined MIPS_EL || defined __MIPSEL__ || defined MIPSEL || defined _MIPSEL +# error "Both BIG_ENDIAN and LITTLE_ENDIAN defined!" +# endif +# define __BYTE_ORDER __BIG_ENDIAN +#elif defined MIPS_EL || defined __MIPSEL__ || defined MIPSEL || defined _MIPSEL +# define __BYTE_ORDER __LITTLE_ENDIAN +#else +# error "Cannot determine current byte order" +#endif + + +/* Define ALIASNAME as a strong alias for NAME. */ +#define strong_alias(name, aliasname) _strong_alias (name, aliasname) +#define _strong_alias(name, aliasname) \ + extern __typeof (name) aliasname __attribute__ ((alias (#name))); Index: gcc-trunk-4.6/libgcc/config.host =================================================================== --- gcc-trunk-4.6.orig/libgcc/config.host 2012-06-22 20:31:35.000000000 +0100 +++ gcc-trunk-4.6/libgcc/config.host 2012-06-22 20:31:37.654759477 +0100 @@ -737,7 +737,7 @@ mips*-*-linux*) # Linux MIPS, either fi ;; mips*-sde-elf*) - tmake_file="$tmake_file mips/t-crtstuff mips/t-mips16" + tmake_file="$tmake_file mips/t-crtstuff mips/t-mips16 t-softfp-sfdf t-softfp-excl t-softfp" case "${with_newlib}" in yes) # newlib / libgloss.