Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638

[Ian Lance Taylor <iant at google dot com>]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:

> There are two places where dse uses knowledge of an address being
> frame_related:
> 1) in this code for const functions.
> 2) in code that deletes stores that die because the function ends.

I think you may be confusing "frame related" with "pushes argument
onto the stack."  A frame related instruction is one which, e.g.,
saves registers on the stack in the function prologue.  That is not
the issue here.  The instructions which push arguments onto the stack
are not frame related.

> As to ian's point in the prior mail:
> 
> > Some processors don't have register offset addressing, so all access
> > to the stack is done by copying and adding registers.  It seems to me
> > that such processors might have trouble with dse.c as currently
> > written.
> 
> 
> I am surprised that this has not bitten us before.  this code has been
> in since the dataflow merge and if some arch really had to do this, i
> would have expected we would have seen this before.  I can understand
> being lucky about this because -fforce-addr is a rarely used flag, but i
> have trouble seeing how this could even bootstrap on a processor that
> had to do it.

The processor's I'm talking about are all DSP processors, rarely used,
certainly never used to bootstrap gcc.

> I can easily turn off the optimization if the -fforce-addr is given.  I
> guess we could add a flag the the md files of the processors that need
> to do this of the form: PROCESSOR_LOADS_STACK_ADDRESSES_INTO_REGS or
> something like this.
> I am a little scared about having to thread a new flag onto registers
> thru the optimization stack at this point. 

dse.c has special optimization for const and pure functions (search
for CONST_OR_PURE_CALL in dse.c).  A safe change would be to remove
that optimization when those functions take arguments on the stack.

Ian