This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: m68k compiler does not build


On Fri, May 14, 2004 at 09:44:21AM -0400, Ian Lance Taylor wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> > > 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.
> 
> In principle, gcc should be able to weigh the costs of loading the
> address into a register versus making the call directly.  Also, in
> principle, a register holding a function address for calls should be
> one of the early ones to spill, because all uses of the register can
> be easily replaced by the constant.  I don't know how well this works
> in practice.

  With m68k-amigaos functions-cse is disabled with -msmall-code. This
  indicates that all branch targets will be with 32k (might lead to
  linker errors if the assumption was wrong) I never liked cse for this
  case.
  AFAICT, function cse happens mostly in loops. Then GCC uses whatever
  non-scratch register is available. However, later in the loop GCC
  might call the cse'd function directly (because the register was
  spilled?).

> In any case, if we decide to define NO_FUNCTION_CSE for the m68k, then
> NO_RECURSIVE_FUNCTION_CSE is clearly useless.

  Right. There are only a few targets that don't define NO_FUNCTION_CSE.

> > > 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)?
> 
> Thanks, that must be the reason.  When calling a function defined in
> the same .o file, gas will change jsr <absolute address> into jsr
> <PC-relative address>.  (gas doesn't seem to use bsr.b, for whatever
> reason).

  As Andreas already pointed out, GCC emits jbsr for GAS which gets
  converted to an appropriate call by GAS.

> Presumably a better way to generate that optimization would be to look
> for calls to symbols defined in the same .o file, rather than
> NO_RECURSIVE_FUNCTION_CSE which only looks for calls to the same
> function.  My understanding is that gcc now has some ability to handle
> calls to local static functions with a different calling convention.

  The appropriate call instruction depends on the distance. GCC doesn't
  have this information.

> I think that on balance my proposed patch is reasonable.

  If disabling FUNCTION_CSE is useful for m68k in general, I would like
  to see that change.

  Gunther


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]