This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Ian Lance Taylor wrote:
> 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.
>
>   
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
>>> 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.
>
>   
The whole point of this part of the optimization was in fact to remove
redundant pushes.
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. 

> Ian
>   


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]