Re: [PATCH] MIPS: microMIPS ASE support

[Richard Sandiford <rdsandiford@googlemail.com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>> >  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).

Yeah, I see your point.  I was thinking that the code claims to "know"
that the LUI and "insn" are both part of the same load address.  So if
the branch was taken, the target of the LUI ought to be dead.  However,
I agree that (even though the code does seem to assume that to some extent)
the assumption is wrong.

E.g. you could have:

	beqz	$2,1f
	lui	$4,%hi(foo)	<-- A

	addiu	$4,$4,%lo(foo)	<-- B
	...
	jr      $31
2:	...
	lui	$4,%hi(foo)	<-- C
	...
1:	addiu   $4,$4,%lo(foo)	<-- D

In this case, the LO16 reloc for D might follow the HI16 reloc for C,
and the LO16 reloc for B might follow the HI16 reloc for A.  AIUI, we'd
consider relaxing A/B but not C/D.  In this case, turning A into a NOP
is wrong, because $4 is still live at D.  If you agree then...

>  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]

...maybe it would be simpler to drop the optimisation if the LUI is any
kind of delay slot.  I think this would simply the code, and I don't think
we'd then need to check for branch relocs.  We'd just have *_norel-like
functions (although not called that any more) to check for every kind
of branch.

I obviously had a bit of a mental block when reviewing this delay slot
stuff, sorry.

Richard