Re: [PATC] MIPS16/GAS: Permit branch swapping with PC-relative insns

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Sat, 6 Aug 2011, Richard Sandiford wrote:
>> >  While at microMIPS branch swapping, I believe it is safe to swap MIPS16 
>> > basic instructions that use the PC-relative addressing mode too with a 
>> > subsequent jump instruction to fill its delay slot.  There are four such 
>> > instructions, namely: ADDIU, DADDIU, LD and LW.  There are two arguments 
>> > standing both at a time that make me think so:
>> >
>> > 1. The use of any complex expression (one that evaluates to but a plain 
>> >    number) as the immediate argument of any of these instructions causes 
>> >    relaxation to trigger (even if the basic form of the instruction is 
>> >    forced with .set noautoxtend or .t suffix) that marks the instruction 
>> >    fixed and inhibits branch swapping.
>> >
>> > 2. All these instructions, if placed in a jump delay slot, use the value 
>> >    of the PC of the preceding jump rather than that of the delay slot 
>> >    itself for calculation -- the value of the PC retrieved therefore 
>> >    remains the same after the swap (note that, contrariwise, this is not 
>> >    the case with the microMIPS ADDIUPC instruction).
>> 
>> I agree the calculated address remains the same.  The problem is that
>> swapping the instructions would change the contents of that address.
>> 
>> Of course, it's vanishingly unlikely that anyone would write a
>> constant addiupc in a reorder block and follow it with an unfilled
>> delayed branch.  Perhaps it could even be called user error.  But given
>> that we have deliberately not swapped until now, changing the behaviour
>> for this one case (and for this one case only) would just be a gratutious
>> break in backwards compatibility.
>> 
>> So, not ok.  However...
>
>  Hmm, I have troubles buying that -- that can be true about any address 
> calculation that gets swapped into a branch delay slot.  And about the 
> only use of such calculation, requiring the resulting address to point to 
> the instruction doing it, is to patch it with something else in 
> self-modifying code, which sounds useless, but let it be that I may be 
> overlooking something here.
>
>  What I do not overlook, and neither you do, is that such code requires a 
> noreorder block, or otherwise GAS is essentially *by definition* free to 
> shuffle code around, transform instructions, add NOPs and do all kinds of 
> weird stuff, so I fail to see why we should be refraining from making this 
> particular change.

So you're agreeing with me that it is very unlikely that such code will
ever be written.  And yet you insist on changing the behaviour for it
(and for nothing else) anyway.

>  Have you got any historical records that back up your position and 
> explain why this statement has originally been placed in?  Otherwise I'd 
> just expect a misunderstanding of how unusually the addition is calculated 
> -- which would be unsurprising to me, as I've seen similar mistakes 
> elsewhere, e.g. up until recently (I believe) QEMU used to get the result 
> of these instructions in delay slots wrong -- hopefully this piece of GAS 
> code is not a workaround for that!

I think this code existed long before QEMU.

Richard