vax call pattern updates

[Michael Sokolov]

Richard Henderson <rth@redhat.com> wrote:

> > If your newly added call and call_value patterns give GCC's optimiser
> > a license to use them whenever it feels like it ...
>
> Incorrect.  RETURN_POPS_ARGS tells the middle end how much is going
> to be popped.  If this value is non-zero, then call_pop *will* be
> generated.

But is this actually enforced, or is there any chance that under different
optimisation levels or whatnot the middle end could pick call because it's more
efficient? Keep in mind that we do have to sacrifice some possible
optimisations in order to maintain VARM/ABI compliance. Let's say I do:

func1(expr1, expr2);
func2(expr1, expr2);

If the optimiser knows that func1 can't change expr1 or expr2, it could push
the arguments once, call func1 without popping the stack, and then call func2
with the same arguments. I believe GCC does this optimisation on other
architectures (please correct me if I'm wrong). However, on the VAX this
optimisation breaks the VARM and some ABIs, and we have to explicitly disable
it and force call_pop even it's not the most efficient. Does this happen now or
not?

> What we want to avoid by having "call" in addition to "call_pop" is
> to avoid degenerate RTL of the form
>
> [RTL picture skipped]

Thanks for the explanation, I got it now! Dave was telling me the same thing,
but your RTL illustration was clearer and now I got it.

> Also consider a function like
>
>   void foo()
>   {
>     bar(0, 1, 2, 3, ..., 255, 256);
>   }
>
> Since bar has more than 255 arguments, we cannot encode how many
> words to pop, and so we have to use "calls $0,bar".  The old code
> would emit the stack adjustment as a part of the call_pop pattern.
> However, this is unnecessary because the immediately following
> return instruction would take care of the stack adjustment.  The
> new code forces the middle end to emit the stack adjust into the
> RTL explicitly, at which point it gets optimized away.

I fully agree here. As far as VARM and classical VAX ABIs are concerned,
functions with more than 255 arguments are simply not permitted, and so in the
GCC land we can simply look at them as GCC extensions and implement them in the
most efficient way.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)