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



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

Just as I feared. :(  Thanks for confirming my suspicions though.

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

This is something that could/would be fixed by introducing a new level of
IR into GCC (which has been discussed many times before).  AFAIK, it is a
critical issue for many future developments in GCC
(http://linuxia64.org/gcc_summit.2001.06.06.html)... but there doesn't
seem to be an active project addressing it [Tree SSA is the closest thing
to a new IR, but it's really not low level enough IMHO].

What is the limiting factor here for a new IR?  Is it the FSF's views on
not letting GCC be used piecemeal as part of a commercial product?  Is it
that there is no agreement on what a new IR should look like (a touchy
subject)?  Or, is it that there is just noone who is interested/has time
to work on it?

I have some time that I could put towards this, but don't want to step on
peoples toes here.  :)

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

> Unlikely to be worth the effort.

Okay, you're probably right.  :)

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/MagicStats/


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