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] Fix and improve ColdFire function prologue/epilogue generation(respin)


Geoff Keating wrote:

But docs I've read explicitly say that it must _NOT_ use scratch
registers:

** EH_RETURN_DATA_REGNO(N) **

The new implementation of the EH uses two registers to pass
information back to catch.  The macro EH_RETURN_DATA_REGNO maps
the values to hard registers.  These registers require stack slots, so
they cannot be scratch registers that are not saved across function
calls.  The macro EH_RETURN_DATA_REGNO will need to be defined and
return appropriate register numbers for the values 0 and 1.  Below is
an example:


I believe this can be made to work; for instance, rs6000 uses r3
through r6 for this purpose.  Maybe the docs are out of date.

I've just noticed that the current gccint.info says exactly the opposite of the old docs I was reading:

  The exception handling library routines communicate with the
  exception handlers via a set of agreed upon registers.  Ideally
  these registers should be call-clobbered; it is possible to use
  call-saved registers, but may negatively impact code size.  The
  target must support at least 2 data registers, but should define 4
  if there are enough free registers.

On m68k, we're using D0 and D1, so it's fine. Perhaps we could also
use A0 and A1, but it says they should be _data_ registers.

It's also not clear whether providing more than 2 registers would
be still a gain even if those additional registers were call-saved.

The documentation I was using is here:

http://gcc.gnu.org/ml/gcc/2002-07/msg00391.html

I've included Aldy in this thread's Cc list to make him aware of
the problem.

Aldy, I'd like to thank you for your insightful paper and also
point out that those debugging tips actually _ARE_ useful, so
please don't dump them!

--
 // 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




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