This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638
Ian Lance Taylor wrote:
> Kenneth Zadeck <email@example.com> writes:
>> There are two places where dse uses knowledge of an address being
>> 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.
I understand that there is something called frame_related which is used
in prologue and epilogue.
in a earlier email i made it clear that inside of dse, i call things
frame related if they are related to the stack frame as these pushes are.
>> 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
>> 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.
The whole point of this part of the optimization was in fact to remove
Given that this is a perfectly useful optimization on most real
architectures, i think that it would be more useful to mark/discover the
ones that it is not useful for rather than turning it off for everyone.