Re: Re[2]: gcc 2.95.2 problem: alloca done within argument list evaluation, corrupts the rest of the argument list

[Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>]

On Jan 14, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>   blah (oof (x, y), b, c, zap (p, q));

> We have to be careful about order of evaluation here too and deal
> with the same issues noted above since the callee is generally
> allowed to modify stack slots for arguments that were passed in.

Anyway, I don't see a problem with allocating stack slots in advance
and evaluating arguments in whatever sequence we prefer.  For example:

allocate 4 slots for `blah'
(parallel
 [allocate 2 slots for `oof'
  (parallel
   [ save x in slot -1 ]
   [ save y in slot -2 ])
  call oof
  release 2 slots
  save result in slot -1 ]
 [ save b in slot -2 ]
 [ save c in slot -3 ]
 [allocate 2 slots for `zap'
  (parallel
   [ save p in slot -1 ]
   [ save q in slot -2 ])
  call zap
  release 2 slots
  save result in slot -4
 ])
call blah
release 4 slots

Any [] blocks within parallels can be freely interchanged (but not
freely interleaved), regardless of what callees do with the stack
slots that contain their arguments.  We could well save b and c first,
if they happened to be readily available in registers, and choose to
call zap just after `oof' so that we only have to reserve one
additional lost for the `oof' call.  Depending on whether arguments
are pushed directly onto the stack (x86), or register windows are
available (sparc) or not (alpha, mips, ppc), we use completely
different strategies WRT storing values into the appropriate slots.
And, in fact, only on x86 was `zap' called before `oof'.

And, again, you obviously already knew all of this ;-)

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them