This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: call_insn's and argument locations
- To: <law at redhat dot com>
- Subject: Re: call_insn's and argument locations
- From: Chris Lattner <sabre at nondot dot org>
- Date: Mon, 2 Jul 2001 11:23:00 -0500 (CDT)
- Cc: <gcc at gcc dot gnu dot org>
> > 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/