[PATCH] Fix up RTL DCE find_call_stack_args (PR rtl-optimization/89965)

Jeff Law law@redhat.com
Tue Apr 16 15:35:00 GMT 2019


On 4/15/19 6:51 AM, Michael Matz wrote:
> Hi,
> 
> On Fri, 12 Apr 2019, Jeff Law wrote:
> 
>>> I don't think this follows. Imagine a pure foo tailcalling a pure bar.
>>> To make the tailcall, foo may need to change some of its argument slots
>>> to pass new arguments to bar.
>> I'd claim that a pure/const call can't tail call another function as
>> that would potentially modify the argument slots.
> 
> I still don't think that what you want follows.  Imagine this:
> 
>   int foo (int i) { ++i; return i; }
> 
> To claim that this function is anything else than const+pure seems weird 
> (in fact this function doesn't access anything that must lie in memory at 
> all).  Now take your off-the-mill ABI that passes arguments on stack, and 
> an only slightly bad code generator, i.e. -O0 on i386.  You will get an 
> modification of the argument slot:
Ugh.  Good point.  But then we're back to the problem with handling of
REG_EQUIV notes for stores into the argument space.  If the callee owns,
has been declared pure/const, but can clobber things like you've shown,
then a REG_EQUIV note on those slots must be avoided.

> 
> foo:
>         pushl   %ebp
>         movl    %esp, %ebp
>         addl    $1, 8(%ebp)
>         movl    8(%ebp), %eax
>         popl    %ebp
>         ret
> 
> So, if anything then the ownership of argument slots is a property of the 
> psABI.  And while we may have been through this discussion a couple times 
> over the years, I'm pretty sure that at least I consistently argued to 
> declare all psABIs that leave argument slot ownerships with the callers 
> (after the call actually happens) to be seriously broken^Wmisguided (and 
> yes, also because it can prevent tail calls that otherwise would be 
> perfectly valid).
Certainly wouldn't disagree that the ABIs ought to own defining this
stuff.  It's just an area where they've been weak in the past.

Jeff



More information about the Gcc-patches mailing list