From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20742 invoked by alias); 26 Jan 2013 10:17:52 -0000 Received: (qmail 20733 invoked by uid 22791); 26 Jan 2013 10:17:51 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com) (74.125.82.180) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Jan 2013 10:17:20 +0000 Received: by mail-we0-f180.google.com with SMTP id k14so571333wer.25 for ; Sat, 26 Jan 2013 02:17:18 -0800 (PST) X-Received: by 10.194.57.82 with SMTP id g18mr12983945wjq.25.1359195438465; Sat, 26 Jan 2013 02:17:18 -0800 (PST) Received: from localhost ([2.26.205.107]) by mx.google.com with ESMTPS id cu7sm1861871wib.8.2013.01.26.02.17.16 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 26 Jan 2013 02:17:17 -0800 (PST) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,"Moore\, Catherine" , "gcc-patches\@gcc.gnu.org" , rdsandiford@googlemail.com Cc: "Moore\, Catherine" , "gcc-patches\@gcc.gnu.org" Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support References: <87y5mfjm4c.fsf@talisman.home> <87622noebh.fsf@talisman.default> Date: Sat, 26 Jan 2013 10:17:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Sat, 26 Jan 2013 03:52:10 +0000") Message-ID: <871ud8tfis.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg01268.txt.bz2 "Maciej W. Rozycki" writes: > On Wed, 23 Jan 2013, Richard Sandiford wrote: >> > Index: config/mips/gnu-user.h >> > =================================================================== >> > --- config/mips/gnu-user.h (revision 195351) >> > +++ config/mips/gnu-user.h (working copy) >> > @@ -137,3 +137,12 @@ extern const char *host_detect_local_cpu (int argc >> > #define ENDFILE_SPEC \ >> > GNU_USER_TARGET_MATHFILE_SPEC " " \ >> > GNU_USER_TARGET_ENDFILE_SPEC >> > + >> > +#undef SUBTARGET_OVERRIDE_OPTIONS >> > +#define SUBTARGET_OVERRIDE_OPTIONS \ >> > +do { \ >> > + /* microMIPS PLT entries are non-microMIPS. */ \ >> > + TARGET_INTERLINK_COMPRESSED = 1; \ >> > +} while (0) >> > + >> > + >> >> Hmm, that sounds like a reason to set TARGET_INTERLINK_UNCOMPRESSED >> rather than TARGET_INTERLINK_COMPRESSED. I.e. we need to avoid direct >> branches from microMIPS code to standard PLTs. >> >> But that means that microMIPS code can't even jump directly to functions >> that have a micromips attribute when the call might go via a PLT. >> TARGET_INTERLINK_(UN)COMPRESSED doesn't cover that case. I think instead >> we need to handle it directly in mips_function_ok_for_sibcall, >> keyed off TARGET_ABICALLS_PIC0. Specific suggestion below. > [...] >> > /* We can't do a sibcall if the called function is a MIPS16 function >> > because there is no direct "jx" instruction equivalent to "jalx" to >> > switch the ISA mode. We only care about cases where the sibling >> > and normal calls would both be direct. */ >> > if (decl >> > - && mips_use_mips16_mode_p (decl) >> > + && ((compression_mode & (MASK_MIPS16 | MASK_MICROMIPS)) != 0) >> > && const_call_insn_operand (XEXP (DECL_RTL (decl), 0), VOIDmode)) >> > return false; >> > >> > - /* When -minterlink-mips16 is in effect, assume that non-locally-binding >> > - functions could be MIPS16 ones unless an attribute explicitly tells >> > + /* When -minterlink-compressed is in effect, assume that non-locally-binding >> > + functions could be MIPS16 or microMIPS unless an attribute explicitly tells >> > us otherwise. */ >> > - if (TARGET_INTERLINK_MIPS16 >> > + if (TARGET_INTERLINK_COMPRESSED >> > && decl >> > && (DECL_EXTERNAL (decl) || !targetm.binds_local_p (decl)) >> > - && !mips_nomips16_decl_p (decl) >> > + && (compression_mode & MASK_MICROMIPS) == 0 >> > + && (compression_mode & MASK_MIPS16) == 0 >> > && const_call_insn_operand (XEXP (DECL_RTL (decl), 0), VOIDmode)) >> > return false; >> >> should be something like: >> >> /* Direct Js are only possible to functions that use the same ISA encoding. >> There is no JX counterpart of JALX. */ >> if (decl >> && const_call_insn_operand (XEXP (DECL_RTL (decl), 0), VOIDmode) >> && mips_call_may_need_jalx_p (decl)) >> return false; >> >> with: >> >> /* Return true if a call to DECL may need to use JALX. */ >> >> static bool >> mips_call_may_need_jalx_p (decl) >> { >> /* If the current translation unit would use a different mode for DECL, >> assume that the call needs JALX. */ >> if (mips_get_compress_mode (decl) != TARGET_COMPRESSION) >> return true; >> >> /* mips_get_compress_mode is always accurate for locally-binding >> functions in the current translation unit. */ >> if (!DECL_EXTERNAL (decl) && targetm.binds_local_p (decl)) >> return false; >> >> /* PLTs use the standard encoding, so calls that might go via PLTs >> must use JALX. */ >> if (TARGET_COMPRESSED >> && TARGET_ABICALLS_PIC0 >> && DECL_EXTERNAL (decl) >> && !targetm.binds_local_p (decl)) >> return true; >> >> /* When -minterlink-compressed is in effect, assume that functions >> could use a different encoding mode unless an attribute explicitly >> tells us otherwise. */ >> if (TARGET_INTERLINK_COMPRESSED) >> { >> if (!TARGET_COMPRESSION && mips_get_compress_off_flags (decl) == 0) >> return true; >> if (TARGET_COMPRESSION && mips_get_compress_on_flags (decl) == 0) >> return true; >> } >> >> return false; >> } >> >> The TARGET_ABICALLS_PIC0 case should deal with the gnu-user.h comment above. > > How about instead of complicating this we simply add support for > microMIPS encoding in the PLT? I think I should be able to squeeze out > some time next week to dust off and retest the binutils patch I've had > pending far too long now. This way we won't have to maintain separate > cases where tail calls may or may not be made via the PLT. > > Note that we need that support sooner or later anyway due to the prospect > of pure-microMIPS processors. Just so I know: what does the PLT patch do for external functions that are jumped to by both microMIPS and non-microMIPS code? Richard