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]

Re: patch to improve i386 epilogue (version 2)



  In message <199809211901.PAA05603@jwlab.FEITH.COM>you write:
  > > So, are we sure we are counting all the generate calls?  What if
  > > GCSE needs to insert multiple calls in various threads of a function
  > > to make a particular call globally redundant?
  > 
  > I was unable to see what you're referring to after taking a quick peek
  > at GCSE.  Could you say more about this and where in GCSE it can happen?
It's a fundamental operation of partial redundancy elimination.  Insert
an evaluation of an expression on one path to make a copy on another
path redundant.

A trivial example can be found at:

http://www.cygnus.com/egcs/gcse.html

That case would insert one computation and delete one computation,
but nothing requires that the number of insertions be less than the
number of deletions.

  > I was assuming that all function calls which defer adjusting the
  > stack are initially created by expand_call and that they are only
  > duplicated by copy_rtx_and_substitute.  Gcc doesn't currently
  > keep track of other internally generated function calls in
  > function_call_count.
Nope.  I don't think that's the case.  Then again, for some reason I
thought all the code to count function calls was now.

  > What about the notion of having a global flag called current_function_is_leaf
  > which is set by scanning for calls prior to local_alloc?  There are
  > situations in which it's useful to known that the function is a leaf.
I don't have a particular problem with that.  However, I would recommend
computing it during life analysis and *not* resetting it later, even
if calls are deleted.  It is absolutely critical that flow and later
code agree on whether or not the current function makes any calls.

  > I can look at this, however I believe that it is still useful to know
  > if the function is a leaf.  For example, Intel recommends always omitting
  > the frame pointer for leaf functions.  One approach is to clear
  > frame_pointer_needed if the function is a leaf.
You can't do that unless you fix the debugger.

If frame pointer elimination interferes with debugging, then it can
never be enabled by default.

It may be the case that gdb on the x86 can handle a frame pointerless
function if it is a leaf (since the stack will not change during the
execution of the function), but one would need to verify that before
enabling any frame pointer eliminations on the x86.
Jeff


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