Is this a peephole optimisation? Or is it about providing accurate
instruction costs for inst?
Question 3:
Storing a2 on the stack is only ever needed if this code path is
taken. Is this even worth to bother with? And is this something that
moving from reload to LRA for the m68k target solves?
// Fredrik Olsson
I have this simple functions:
int sum_vec(int c, ...) {
va_list argptr;
va_start(argptr, c);
int sum = 0;
while (c--) {
int x = va_arg(argptr, int);
sum += x;
}
va_end(argptr);
return sum;
}
When compiling with "-fomit-frame-pointer -Os -march=68000 -c
moveq #1,%d0
jsr (%a3) | Calling mul() again, will clobber.
moveq #0,%d1
jsr (%a2) | This call to my_assert() d2 is incorrectly assumed to
be still valid from previous call. HOW can I fix this?
moveq #0,%d0
movem.l (%sp)+,#3084
rts
// Fredrik Olsson
Hi.
As a learning project I have tried to implement "fastcall" for m68k
target. I have largely sneak peeked at the i386 code to do this.
My "fastcall" convention uses d0-d2, a0-a1 and fp0-fp2 for arguments.
This also means that d2 is clubbed by calls to functions using the
"fastcall" ABI. I updat