Re: call_insn's and argument locations

[law at redhat dot com]

  In message <Pine.LNX.4.33L2.0107021116360.24955-100000@nondot.org>you write:
  > Just as I feared. :(  Thanks for confirming my suspicions though.
One thought would be to attach the modified memory locations to the
CALL_INSN much like we already do for registers.  That may cause some
downstream problems with MEMs showing up in places where we didn't
expect them.  But those should be solvable.

If you wanted to go even further, what I'd do is attach source/target 
pairs to the CALL_INSN.  ie, the pseudo register holding the value
and the destination for where it's passed to the target function.

By doing that, we'd have a lot of the information we'd need to do a
more gradual lowering of function calls.

  > 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].
Yes.  I know.  However, I don't think we want to go about introducing a
new IR.  Instead I think we want to have a higher form of our existing
RTL IR.

  > 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?
Time mostly.  I've been working on some stuff and I think I've got a
workable model (as I hinted at in a message on an unrelated topic).  I
believe the basic model is sound and fits into GCC rather well.

jeff