This is the mail archive of the
mailing list for the GCC project.
Re: m68k compiler does not build
- From: Gunther Nikl <gni at gecko dot de>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 May 2004 14:56:25 +0200
- Subject: Re: m68k compiler does not build
- References: <firstname.lastname@example.org>
On Thu, May 13, 2004 at 10:58:36AM -0400, Ian Lance Taylor wrote:
> NO_FUNCTION_CSE means that gcc should not try to optimize function
> calls by storing the address of the function in a register and then
> doing calls via the register. This is defined by most targets.
I never noticed that. Since m68k (my main target) does function_cse
I assumed that its valuable optimization done on all supported GCC
> This seems reasonable, as most modern processors have a call instruction
> which is more efficient than the instructions required to load a
> function address. However, this is probably not true of the m68k--the
> m68k has a two-byte call register instruction, but a call to a
> function is ordinarily a six-byte instruction. I would guess that
> call to register is faster, so it is reasonable that the m68k does not
> define NO_FUNCTION_CSE.
A word relative branch takes 4 bytes and its short form 2 bytes.
Then function CSE is not always beneficial: it eats up a register and
requires a move if GCC stored the function address in a data register
since indirect branches have to be done through an address register.
I wonder if functions-cse is really beneficial for m68k.
> Defining NO_RECURSIVE_FUNCTION_CSE means that gcc should not perform
> this optimization when making a recursive call. Unfortunately, I
> can't think of any target specific reason why this makes sense. I
> could imagine that it would be a bad idea in general, since it would
> make the compiler less likely to recognize a case of tail recursion.
> However, I can't think of any reason why on the m68k in particular it
> is better to use an explicit call only when doing a recursive call.
Maybe the call can use the relative byte (bsr.b) or word (bsr.w) calls
(as long as the function size does not exceed 32k)?
> It seems to me that we should just remove the macro
> NO_RECURSIVE_FUNCTION_CSE from the compiler. Unfortunately, with no
> an m68k simulator, there is no easy way for me to test the effects of
> this on the m68k. However, it seems unlikely to be a correctness
Then its an efficiency issue.
> So I propose this patch. This at least lets the m68k compiler build.
> Even if approved, I'll run the m68k compiler tests before checking
> this in, but I don't have any way to do any further testing.
I have an m68k system but I never tried to boostrap any 3.x version.
Once I did an unoptimized 3.2.2 build with only C enabled. I always
cross-build a native GCC version.
I don't think m68k will break if NO_RECURSIVE_FUNCTION_CSE is removed.