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


Kenneth Zadeck <zadeck@naturalbridge.com> writes:

> 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. 

Sorry, I missed that.  Frame related has a specific meaning in gcc.
The problem here is specifically pushing arguments on the stack, not
any other part of frame usage.


> > 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. 

The obvious first cut is that you only have to worry about const
functions for which parameters are stored on the stack without using
push instructions.  Admittedly that includes newer x86 processors.

If you want to do this safely then you need to know which stores are
for arguments.  I don't see any way around that.  Focusing on
-fforce-addr amounts to focusing on the current state of RTL
optimizations, rather than on what is valid.

We can go that way--something along the lines of Uros's patch to use
memory_addr_noforce--if nobody wants to imlement the real solution.
But we need some detailed comments in the code, and we need some
complete test cases to find the future breakage.

Ian


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