Daniel Jacobowitz wrote:
> > Maybe I'm missing something, but both the old and the new code
> > add 8 byte more to sp than they subtracted before. How is this
> > supposed to work?
> It's supposed to do that, according to GCC. Build something with -S
> -pg and look at it.
Well, I don't have a 32bit compiler here ATM, only a highly
experimental 64bit one. :-) But I found in the GCC Code this
snippet in /config/mips.mips.h:
/* Output assembler code to FILE to increment profiler label # LABELNO
for profiling a function entry. */
#define FUNCTION_PROFILER(FILE, LABELNO) \
if (TARGET_MIPS16) \
sorry ("mips16 function profiling"); \
fprintf (FILE, "\t.set\tnoreorder\n"); \
fprintf (FILE, "\t.set\tnoat\n"); \
fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n", \
reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]); \
fprintf (FILE, "\tjal\t_mcount\n"); \
fprintf (FILE, \
"\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from stack\n", \
TARGET_64BIT ? "dsubu" : "subu", \
Pmode == DImode ? 16 : 8); \
fprintf (FILE, "\t.set\treorder\n"); \
fprintf (FILE, "\t.set\tat\n"); \
This means, 8 byte is indeed ok for 32bit targets, a 64bit one
would differ by 16 byte (and won't work with the code you've
Nevertheless, IHMO it would be a good idea to support both targets.
> > Why do you save and restore $6, $7, seemingly without using them?
> Because they were already there; I was trying to keep this patch
> minimal. My MIPS assembly knowledge, as I said, is a little scanty.
Hm, and I have too little knowledge about the profiler to give
helpful advice here.