On Sat, 24 Nov 2001, Rafal Boni wrote:

> Folks:
> 	In the process of getting the new toolchain working on BE MIPS
> 	platforms, I've found that profiling is totally broken due to
> 	the way the GCC profiler prologue is coded (it emits assembly
> 	code that was hand-scheduled and breaks in the face of PIC).
>
> 	I'm including the fixed up profiler prologue macro below (the
> 	problem was that previous to this fix, the stack pre-adjustment
> 	had been hand-scheduled into the delay slot of the `jal', which
> 	broke in the .abicalls/PIC case as the assembler re-wrote the
> 	`jal' into a `load $t9; jalr $t9; restore $gp' sequence, pushing
> 	the stack pre-adjustment until a point *after* the jump).
>
> 	It had been suggested on the GCC list that while fixing this
> 	it might be even better to get rid of the `.set noreoder'/`.set
> 	reorder', as after all the assembler should know better than the
> 	compiler how to schedule the instructions.

Rafal,

To me it sounds like the assembler is at fault for not considering the
delay slot when it performs the .abicalls expansion.  The correct
expansion by the assembler should be:

	load $t9, <sym> ; jalr $t9 ; <bdslot insn> ; lw $gp, offset($gp)

Depending at what level the assembler perfroms the reordering of
instructions whould allow us to decide if reorder is allowable:

- reorder optimisation *before* .abicalls expansion:

	Your 'nop' insn in the delay slot would get replaced by the stack
	frame addjustment and you will be back to the original problem
	again
	You need 'set noreorder' to resolve this situation

- reorder optimisation *after* .abicalls expansion:

	You 'nop' insn from the delay slot will be pushed after
	the restore of $gp code and later eliminated

	'set reorder' is perfectly legit in this case, and will eliminate
	will optimize out the nop


You wouldn't be asking on this list if the first case failed, therefore we
can conclude that the 2nd case applies, and unless there is another
unconsidered factor "reorder" produces correct code around a the extra nop
will be pushed to a save location and later eliminated.

Have you looked at GAS to see what is happening at that level, and if
the .abicalls expansion can be fixed there ???

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org