Re: [m68k] use precomputed values from current_frame

[Bernardo Innocenti <bernie at develer dot com>]

Richard Henderson wrote:
> On Tue, Sep 23, 2003 at 07:53:03PM +0200, Bernardo Innocenti wrote:
>
> > Some instrumentation also reveals that the ia64 approach is broken.
> > The reload_completed flag is never true when m68k_compute_frame_layout()
> > is called. I've tested it with several combinations of optimization flags.
> > This has probably been broken by the unit-at-a-time mode.
>
> How can this possibly be true?  reload_completed is set by
> rest_of_handle_new_regalloc after reload, and is not cleared
> until after rest_of_handle_final.

Hmmm... I've looked into it again. reload_completed was
always 0 in m68k_compute_frame_layout() because it was just
being used in a few places.

I've restored my diagnostic output at the end of
m68k_compute_frame_layout(). It looks like this:

 fnotice(stderr, "%s: reload_completed=%d size=%d mask=%04x\n",
   current_function_name, reload_completed, current_frame.size,
   current_frame.reg_mask);

Now that I also call m68k_compute_frame_layout() also in
m68k_output_function_(prologue|eplilogue)(), the output
looks like this:

vsnprintf: reload_completed=0 size=0 mask=3cfc
vsnprintf: reload_completed=0 size=0 mask=3cfc
vsnprintf: reload_completed=0 size=0 mask=3cfc
vsnprintf: reload_completed=0 size=0 mask=3cfc
vsnprintf: reload_completed=0 size=0 mask=3cfc
vsnprintf: reload_completed=0 size=0 mask=3cfc
vsnprintf: reload_completed=1 size=0 mask=3cfc
vsnprintf: reload_completed=1 size=0 mask=3cfc

I believe the last two lines refer to the call done
in prologue/epilogue generation.

Frame computation seems to be invoked 8-12 times
per compiled function, and caching the computed
values only after reload results in just one hit.

We either drop this optimization altogether or find
a smarter way to detect when we need to recompute
the frame info.


> > Some additional diagnostic output revealed that the information computed
> > in m68k_compute_frame_layout() never changes between invocations, so
> > it's safe to reuse it regardless of reload_completed.
>
> This is most definitely false.  It *will* change whenever reload
> has to allocate more stack space for spills.

Silly me... you're right. It's just that it happens very sparingly
on m68k, perhaps because there are so many registers. I had to
compile complex code from the Linux kernel to spot cases swhere
something did change.

Here the frame size changes several times (-O2 needed):

number: reload_completed=0 size=68 mask=3cfc
number: reload_completed=0 size=68 mask=3cfc
number: reload_completed=0 size=72 mask=3cfc
number: reload_completed=0 size=72 mask=3cfc
number: reload_completed=0 size=72 mask=3cfc
number: reload_completed=0 size=72 mask=3cfc
number: reload_completed=0 size=76 mak=3cfc
number: reload_completed=0 size=76 mask=3cfc
number: reload_completed=0 size=76 mask=3cfc
number: reload_completed=0 size=76 mask=3cfc
number: reload_completed=0 size=76 mask=3cfc
number: reload_completed=0 size=76 mask=3cfc
number: reload_completed=1 size=76 mask=3cfc
number: reload_completed=1 size=76 mask=3cfc

And here more registers get allocated (-O3 needed):

simple_strtoul: reload_completed=0 size=0 mask=040c
simple_strtoul: reload_completed=0 size=0 mask=040c
simple_strtoul: reload_completed=0 size=0 mask=041c
simple_strtoul: reload_completed=0 size=0 mask=041c
simple_strtoul: reload_completed=0 size=0 mask=041c
simple_strtoul: reload_completed=0 size=0 mask=041c
simple_strtoul: reload_completed=0 size=0 mask=041c
simple_strtoul: reload_completed=0 size=0 mask=041c
simple_strtoul: reload_completed=1 size=0 mask=041c
simple_strtoul: reload_completed=1 size=0 mask=041c

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html