[m68k] Fix and improve ColdFire function prologue/epilogue generation

[Bernardo Innocenti]

Richard Henderson wrote:
>>+  /* offsets relative to ARG_POINTER.  */
>>+  HOST_WIDE_INT frame_pointer_offset;
>>+  HOST_WIDE_INT hard_frame_pointer_offset;
>>+  HOST_WIDE_INT stack_pointer_offset;
> 
> Never set?

That's because the structure comes from the i386
back-end.

We could remove hard_frame_pointer_offset, but I'd rather keep
stack_pointer_offset and frame_pointer_offset so I can move the
computation away from m68k_initial_elimination_offset().


>>+  if (TARGET_COLDFIRE)
>>+    {
>>+      /* on Coldfire add register save into initial stack frame setup, if possible */
>>+      for (regno = 0; regno < 16; regno++)
>>+        if (m68k_save_reg (regno))
>>+          num_saved_regs++;
> 
> Seems like you could compute this during the loop to find
> them in the first place.  At minimum, reuse the computed
> mask rather than calling m68k_save_reg again.

Ok, I'll move register mask computation to the top and merge
it with the ColdFire specific code. This will also make the
code much more readable than before.


> As for testing problems on older systems, I think it would
> make sense to make the stack layouts for coldfire and non
> as similar as possible, to avoid these sorts of things.

Right.


> For instance, I don't see any particular *need* to use
> post-dec movem on '020 systems; we only do it now because
> we always have.  It wouldn't be any slower, afaics, to go
> ahead and use (%sp) there as well.

Hmmm does 'movem.l regs,(An)' work on m68k the same way it
does on ColdFire? That is, does it increment the
destination pointer after each write?

I will look at Motorola's user manual in case it's clearly
documented.


> I would think you'd have two goals in designing a stack
> frame layout for 68k.  (1) preserve the historical 
> fp_n = *(fp_(n+1)) style linkage, to allow historical
> stack walking code to continue to work, and (2a) minimize
> number of instructions (2b) minimize instruction size.
> 
> I'd think you'd have only two cases there:
> 
>   frame_pointer_needed:
> 
> 	link %fp,-(frame_size + saved_regs_size)
> 	movem (mask-without-fp), -saved_regs_size(%fp)
> 
> 	I guess on coldfire you have to compute that offset
> 	into a call-clobbered address register first.
> 
>   !frame_pointer_needed:
> 
> 	suba	(frame_size + saved_regs_size), %sp
> 	movem	(%sp), (mask-with-a6-if-needed)
> 
> 	I also guess you might need to offset %sp by 
> 	current_function_pretend_args_size or something,
> 	but I'd expect that to be zero most of the time.

I think we'd still have an additional case where m68k and
ColdFire would differ: when frame_size is zero, m68k targets
don't need to pre-decrement SP because they can let movem do
it as a side-effect of the post-increment.

On ColdFire, we still need to increment it manually.


> The two yield very different layouts (registers at top
> vs registers at bottom), but I don't see anything wrong
> with that.

Except for the very common off-by-1 bugs in locally
declared arrays, but that's none of our business ;-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html