Re: IA32 redundant stack adjusts

[Mike Stump <mrs at windriver dot com>]

> Date:   Fri, 14 Jan 2000 12:31:26 -0800
> From: Zack Weinberg <zack@wolery.cumb.org>

> What's wrong with this picture?  The LOG_LINKS list of insn 11 is
> nil.  That is because flow.c has a general policy of not generating
> data flow info for the stack pointer.

Sounds like we should data flow the stack pointer.

> The commentary says over and over "we don't need this" but never
> explains why.

Easy, if we don't ever do anything with it, no need to collect the
data.  If we want, we can now do something with it and expose it fully
to the optimizer.

> and then you discover that combine.c explicitly refuses to combine
> stack pointer operations.

>   /* Don't eliminate a store in the stack pointer.  */
>   if (dest == stack_pointer_rtx
>       /* ... */ )
>     return 0;

I think this can go, if you (or someone else) wants to support this.

When we start down this road, we'll notice there are instructions that
use the stack pointer that doen't say they do (and we will need to
update them) and various places in the compiler that need to let the
other parts of the compiler know more about the stack pointer.  For
example, code like:

        /* USE of hard_frame_pointer_rtx added for consistency; not clear if
	   really needed.  */
	emit_insn (gen_rtx_USE (VOIDmode, hard_frame_pointer_rtx));
	emit_insn (gen_rtx_USE (VOIDmode, stack_pointer_rtx));
	emit_indirect_jump (temp);

is kinda fun to read and see.  Makes you wonder...  Also, if the
compiler gets confused about stack being needed in this case, what
other types of new cases will there be?