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
