MEM flags and stack temps

[Joe Buck]

>     Yes!  With the second approach, it will then be straightforward to get
>     rid of the huge number of dead stores we get on C++ code (currently
>     once an object is assigned to the stack and we write it, the compiler
>     is incapable of seeing that the value is not needed).  All (ok, big
>     "all") we need to do is extend dead code elimination to work on stack
>     slots where addresses are not taken (currently the dead code
>     eliminator in dce.c believes that all writes to memory are necessary
>     under all conditions).
> 
> The problem is timing: you also want to be able to do CSE and loop
> optimizations on the addresss of temporaries that aren't eliminated if they
> are outside the addressable range of the machine.

Clearly I'm missing something.  In the cases I'm talking about that seem
to be the main cause of poor C++ performance, after inlining there are no
addresses taken at all: objects are passed by reference to an inline
function and then dereferenced, but if we have ADDRESSOF(STACK_SLOT x)
and then dereference it the ADDRESSOF just cancels out.  So stack slots
work like another type of register.  Maybe even using a term like stack
slot is misleading, as they work like pseudo registers.

If we have an object whose address is taken we have to worry about
aliasing so dce can't kill stores.

You seem to be thinking of a completely different problem.  Is this an
issue with the ordering of the passes?