Re: [PATCH] MIPS: microMIPS ASE support

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

On Tue, 14 Dec 2010, Richard Sandiford wrote:

> >  Yes, I think it will make it easier for us both to keep track of what has 
> > been addressed and what not.  I have no technical problem with including 
> > further changes in a separate patch.
> 
> Thanks.  For avoidance of doubt, please make any updates (with the FIXMEs
> fixed, for instance), relative to the original.

 Yes, this is what I assumed too.

> >  Undefined weak symbols are, well, undefined, so they have resolved to nil 
> > and are meant never to be jumped to, so we don't want to error out on them 
> > just because they do not have the ISA bit set and a JALX therefore 
> > required could not be used for some reason, like the invocation being a 
> > sibling call or because it would not satisfy the fixed delay slot 
> > dependency.
> 
> OK, makes sense.  Please update the comment to something like:
> 
>   /* Calls from 16-bit code to 32-bit code and vice versa require the
>      mode change.  However, we can ignore calls to undefined weak symbols,
>      which should never be executed at runtime.  This exception is important
>      because the assembly writer may have "known" that any definition of the
>      symbol would be 16-bit code, and that direct jumps were therefore
>      acceptable.  */

 Done, thanks.

> >  Only link variations of branches and jumps have a fixed-size delay slot 
> > -- that's because the link register is set to a fixed offset from the 
> > delay-slot instruction (either four as with JAL or two as with JALS).  Of 
> > all such jumps and branches only JALX does not have a JALXS counterpart 
> > (regrettably, as it would have made life of software much, much easier).
> >
> >  I've explained the meaning of 0 below -- it's unsafe to return this value 
> > for a variable-size delay slot.
> 
> Hmm, I was thinking of the case where there was no branch _after_
> the LUI, and where the instruction after the LUI could then become
> the delay slot for a variable-length branch before the (deleted) LUI.
> But yeah, I can see that 0 isn't correct if there is a branch immediately
> after the LUI.

 Well, if we have code like this:

	branch	...
	 LUI	...
	insn	[...]

(where for the purpose of this consideration BRANCH may also be a jump) 
then LUI cannot be entirely deleted and INSN moved into the slot of BRANCH 
no matter if INSN is a branch or an computational instruction.  All we can 
do in this case is to see if there is a corresponding BRANCHC instruction 
and use it to swap BRANCH with and then delete the LUI if so, or otherwise 
shrink the LUI to a 16-bit NOP if BRANCH permits or can be swapped with 
BRANCHS to permit a 16-bit delay-slot instruction.  If neither is 
possible, then the LUI is merely substituted with a 32-bit NOP (although 
the effect is purely cosmetical in this case; perhaps we should just back 
out).

 Also with the recent update to LUI relaxation code I think we should 
simply disallow the optimisation if a LUI is in a delay slot of an 
unconditional branch -- we have no way to verify the corresponding LO16 
reloc really belongs to this LUI instruction in that case.  This will let 
us simplify code (which has become a little bit hairy by now IMO) a little 
bit I would guess.  [FIXME]

> >  Hmm, we could do this in two passes over the reloc table (still O(n)) and 
> > first make a fast auxiliary data structure (e.g. a hash) to keep addresses 
> > of branch and jump relocations.  Given linker relaxation is off by default 
> > I'd vote for this as a future improvement.
> 
> Yeah, I'd wondered about that, but then we'd need to measure whether that
> made things better or not.  I'm OK with leaving it.

 The breaking point may be high -- we'd have to benchmark a program with a 
suitably high number of relocations to decide whether to go for that at 
all.  And then perhaps only enable the optimisation selectively at the run 
time, based on the size of the reloc table and the expected density of 
HI16/LO16 reloc pairs within.  And even then, in a typical compilation 
there are relatively few final links, so shaving a couple of seconds off a 
compilation that otherwise takes half a dozen of minutes may be missing 
the point.

  Maciej