This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS: microMIPS ASE support
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Ilie Garbacea <ilie at mips dot com>, Joseph Myers <joseph at codesourcery dot com>, binutils at sourceware dot org, Chao-ying Fu <fu at mips dot com>, Rich Fuhler <rich at mips dot com>, David Lau <davidlau at mips dot com>, Kevin Mills <kevinm at mips dot com>, Catherine Moore <clm at codesourcery dot com>, Nathan Sidwell <nathan at codesourcery dot com>, Nathan Froyd <froydnj at codesourcery dot com>
- Date: Thu, 16 Dec 2010 11:16:23 +0000 (GMT)
- Subject: Re: [PATCH] MIPS: microMIPS ASE support
- References: <alpine.DEB.1.10.1005181806590.4023@tp.orcam.me.uk> <87y6fa9u3t.fsf@firetop.home> <alpine.DEB.1.10.1007112325020.2824@tp.orcam.me.uk> <876302kqvu.fsf@firetop.home> <alpine.DEB.1.10.1012061924490.5345@tp.orcam.me.uk> <871v5n9m7e.fsf@firetop.home> <alpine.DEB.1.10.1012131400320.4142@tp.orcam.me.uk> <g4bp4oscro.fsf@richards-desktop-2.stglab.manchester.uk.ibm.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