This is the mail archive of the gcc@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]

Re: egcs-1.1 status



  In message <19980823050327.A683@kali.lrz-muenchen.de>you write:
  > > The important issue is argument setup on the caller side, not the
  > > callee side.
  > 
  > In the __switch_to case this is done by a assembly function, and thus no 
  > problem. The question is only whether it can be told to gcc reliably 
  > that it should expect the variables in these registers.
I believe regparm would be OK in this situation (only allowing regparm
functions to be called from assembly code until reload is fixed).  This
may in fact be the compelling reason to keep regparm even though it
can not be correctly implemented on the caller side yet.

It would be helpful if someone could forward me the testcase which
originally exposed te callee side, even if it was for egcs-1.0.3 so
I can examine it more carefully.

It may even be possible to get the compiler to warn/error for a C call
to a regparm function.


  > I recognize that it is not nice because it prevents lots of optimizations
  > (possible solved by using local fixed register variables instead, is it 
  > guranteed that these registers won't be thrashed between function entry
  > and first use?)
Local variables assigned to registers have different semantics.  The
compiler will track when those variables have a live value, and in
sections of code where the value is not live the compiler can/will use
the register for other purposes.

  > Regarding the problem of eax as the return value registers: when all 
  > functions used in __switch_to() are inlined, and __switch_to() itself
  > is a void, would that solve the problem?
__switch_to would not be allowed to call any functions which return a
value either.

jeff


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