Re: RFC: Possible tweak to MIPS16/microMIPS PLT choice

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Mon, 7 Oct 2013, Richard Sandiford wrote:

> >  I still owe you a new version of the test suite part proposed there, I 
> > remember -- I just couldn't allocate any time to do that, sigh...
> 
> NP -- I have a harnaess I'm happy with, I just need to fill in the details :-)

 I explicitly covered some corner cases in my proposal, I'd prefer it 
didn't get lost and therefore some form of the original test suite made 
its way into our sources.  I reckon your main concern was the redundancy 
of some cases and the lack of machine code matching.

> >  Hmm, I'm not sure if I follow you.  The choice looks obvious to me: we 
> > want to use microMIPS PLT entries whenever possible because they are 
> > smaller (the whole purpose of the creation of the microMIPS ISA).  In your 
> > scenario:
> >
> > 1. We obviously can use a microMIPS PLT entry because we have microMIPS 
> >    code in the object being linked.
> >
> > 2. We obviously can't use a microMIPS PLT entry because the presence of 
> >    MIPS16 code precludes the use of microMIPS code.
> >
> > 3. We obviously can't use a microMIPS PLT entry because we only saw 
> >    standard MIPS code and therefore we want to run it on a standard MIPS 
> >    processor.
> >
> > 4. We obviously can use a microMIPS PLT entry because we have microMIPS
> >    code in the object being linked.
> >
> > -- so what's unclear about it?
> >
> >  In the absence of JAL relocations it's the output microMIPS ELF file 
> > header flag that makes BFD decide whether to use microMIPS or standard PLT 
> > entries and it seems obvious and straightforward to me.  Why do you think 
> > CALL relocations should be treated specially in any way?  Am I missing 
> > anything?
> 
> Yeah, I should have been more explicit, sorry.  I thought the justification
> for using MIPS PLTs in microMIPS objects, rather than converting MIPS
> JALs to JALXs, was that we wanted to use the caller's encoding to avoid
> the hit of a mode change.  Wouldn't the hit be just the same if the call
> is coming indirectly through a JALR rather than directly through a JALX?

 The hit was mainly a concern for MIPS16 mode switches and I believe is 
irrelevant for indirect calls because for these there is no branch 
prediction and hence no need to invalidate state already prefetched into 
the pipeline.

> That is, I wasn't sure why we were treating:
> 
>         jal     foo
> 
> and the equivalent of:
> 
>         lw      $25, %call16(foo)($25)
>         jalr    $25
> 
> differently when deciding the encoding of foo.  With JAL->JALX conversion,
> both forms can call either "standard" or "compressed" code, but as things
> stand, they don't influence the choice in the same way.

 A JAL->JALX conversion could be made, but the issue here is there is no 
equivalent available for the J instruction.  So to avoid a further 
complication such a conversion isn't made at all.  And don't forget the 
JAL->BAL or J->B relaxation that we do want to make whenever possible.  
Overall a lot of hassle for a questionable gain.  Someone who wants to 
squeeze out as much as possible from memory available won't be using 
mixed-mode binaries anyway.

> So going back to the list above, the equivalent for JAL relocations is:
> 
> 1. microMIPS JAL + HI/LO ref -> microMIPS PLT
> 2. MIPS16 JAL    + HI/LO ref -> MIPS16 PLT
> 3. MIPS JAL      + HI/LO ref in non-microMIPS object -> MIPS PLT
> 4. MIPS JAL      + HI/LO ref in microMIPS object     -> MIPS PLT
> 
> where (2) and (4) give different results from the GOT CALL case.
> I was thinking the GOT CALL and JAL cases could be handled in the same way.

 Well, as noted above the objective is different for JAL vs GOT CALL, so I 
don't think the two cases need to match each other.  It's fine for GOT 
CALL to switch modes -- although will it really?  Does the GOT entry 
created to satisfy a CALL relocation point to a PLT slot rather than a 
lazy binding stub in a non-PIC abicalls executable?  That would look like 
an unnecessary performance pessimisation to me -- why two indirect calls 
instead of one only?

  Maciej