"Maciej W. Rozycki" <ma...@codesourcery.com> 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
