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: call_insn's and argument locations


  In message <Pine.LNX.4.33L2.0106291809210.4788-100000@nondot.org>you write:
  > 
  > Is there any good way to find out where the arguments to a call_insn are?
It's fairly easy to find arguments which are in registers (the call insn
itself will have a bunch of USEs attached to it for arguments).

What is bloody hard to find right now is arguments that are passed on the
stack.

Personally, the fact that we expose this level of ABI/architectural detail
as soon as we leave the tree representation is bad, but I'm not at a point
where I'm ready to attack that problem.

  > On another topic, is there any particular reason why expand_call doesn't
  > cache the locations of the function call arguments in the tree type that
  > represents the function?  Every time a function is called, GCC has to go
  > through the trouble of finding registers & stack slots to put arguments
  > in... shouldn't this be invariant across different calls to the same
  > function/same prototype?
Unlikely to be worth the effort.


  > If so, couldn't this be cached in the tree expression?  It seems like
  > this could save a significant amount of time (although it certainly be
  > smart to profile it before making crazy assertions about it. :)
I think if you look at the profiles you'll see that code isn't critical by
any stretch of the imagination.
jeff


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