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 <Pine.LNX.3.96.980822112054.3907C-100000@penguin.transmeta.com>you write:
  > > I don't know.  But I can say for sure that using regparm is going to
  > > cause problems on the x86.  They might get away with it for a while,
  > > but in the end the compiler is going to silently generate incorrect
  > > code.  It's not going to matter what compiler version they use, in
  > > the end all of them are going to break.
  > 
  > Note that the kernel uses "regparm" only for certain functions, and I'm
  > intentionally avoiding using it for anything where we use a function
  > pointer, because that seems to be the major thing that triggers the
  > problems.
The problem is that reload can/will silently trash registers holding
parameters while trying to satisfy reloads for later register loads.
Note that reloads can be triggers in many non-obvious ways on the x86
due to the way the machine description was written.

No code using regparm is safe.  Again, you might get away with it for
a while, but in the end, it's going to generate incorrect code.  And
(of course) the places where incorrect code is generated will vary
from one version of the compiler to the next due to subtle differences
in the generated code.

I strongly recommend against using regparm until such time as someone
can rewrite reload to deal with machines with small register classes
like the x86.

I would *love* for someone to start revamping reload since the benefits
both in terms of efficiency of the generated code and the user interface
issues with the "asm" which use too many regs are significant.


  > The case where regparm is a noticeable win is things like "wrapper
  > functions", where we have a internal function that is not really meant to
  > be used directly, but that is exported through an inline (or more commonly
  > a define) that passes specific immediates as arguments to the function. It
  > often makes the function itself much nicer, but more importantly it makes
  > the calling sequence a lot more pleasant to look at. 
  > 
  > It also happens to be the best case for regparm - there is no register
  > pressure in actually setting up the argument registers. 
Well, I'd still recommend against it.  Though you're much less likely
to trigger the problems in these kinds of cases.  But are you willing
to take that chance?  Knowing the issues in the compiler, I certainly
would not be willing to take the chance.

  > Jeff, you always seem to take compiler problems to be something really
  > negative. I would urge you and the other egcs developers to see this as
  > something _positive_ where you can actually look into the problem and try
  > to fix it, instead of throwing up your hands and saying "oh, gods, I can't
  > handle this, let's remove the feature".
Please do not make this personal again.  This is a purely technical
issue.  *I* do not have the time to rewrite reload.  And as I mentioned
I would love for someone to step up and do that.  Until such time as
reload is rewritten, using regparm is a horribly bad thing to do
because it will eventually end up causing you problems.

  > Or are you going to remove inline assembly too? 
That's not fair and you know it.  Please stick to the technical issues
at hand instead of making personal attacks.  This kind of comment is 
more likely to encourage me to ignore you instead of help you.

jeff


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