Bernd Schmidt <ber...@codesourcery.com> writes:
> On 08/03/11 17:38, Richard Sandiford wrote:
>> Bernd Schmidt <ber...@codesourcery.com> writes:
>>> +@findex simple_return
>>> +@item (simple_return)
>>> +Like @code{(return)}, but truly represents only a function return, while
>>> +@code{(return)} may represent an insn that also performs other functions
>>> +of the function epilogue. Like @code{(return)}, this may also occur in
>>> +conditional jumps.
>>
>> Sorry, I've forgotton the outcome of the discussion about what happens
>> on targets whose return expands to the same code as their simple_return.
>> Do the targets still need both "return" and "simple_return" rtxes?
>
> It's important to distinguish between these names as rtxes that can
> occur in instruction patterns, and a use as a standard pattern name.
> When a "return" pattern is generated, it should either fail or expand to
> something that performs both the epilogue and the return. A
> "simple_return" expands to something that performs only the return.
>
> Most targets allow "return" patterns only if the epilogue is empty. In
> that case, "return" and "simple_return" can expand to the same insn; it
> does not matter if that insn uses "simple_return" or "return", as they
> are equivalent in the absence of an epilogue. It would be slightly nicer
> to use "simple_return" in the patterns everywhere except ARM, but ports
> don't need to be changed.
>
>> Do they need both md patterns (but potentially using the same rtx
>> underneath)?
>
> The "return" standard pattern is needed for the existing optimizations
> (inserting returns in-line rather than jumping to the end of the
> function). Typically, it always fails if the function needs an epilogue,
> except in the ARM case.
> For shrink-wrapping to work, a port needs a "simple_return" pattern,
> which the compiler can use even if parts of the function need an
> epilogue. So yes, they have different purposes.
>
>> I ask because the rtl.def comment implies that those targets still
>> need both expanders and both rtxes. If that's so, I think it needs
>> to be mentioned here too. E.g. something like:
>>
>> Like @code{(return)}, but truly represents only a function return, while
>> @code{(return)} may represent an insn that also performs other functions
>> of the function epilogue. @code{(return)} only occurs on paths that
>> pass through the function prologue, while @code{(simple_return)}
>> only occurs on paths that do not pass through the prologue.
>
> This is not accurate for the rtx code. It is mostly accurate for the
> standard pattern name. A simple_return rtx may occur just after an
> epilogue, i.e. on a path that has passed through the prologue.
>
> Even for the simple_return pattern, I'm not sure reorg.c couldn't
> introduce new expansions in a location after both prologue and epilogue.
Ah, OK, thanks. That clears up my confusion, and the new md.texi
documentation looks nicely thorough.
One of the points I was trying to make (badly) was that rtl.def
and rtl.texi, which both document the rtx rather than the pattern,
didn't seem to agree on what the semantics were. rtl.texi says:
@findex simple_return
@item (simple_return)
Like @code{(return)}, but truly represents only a function return, while
@code{(return)} may represent an insn that also performs other functions
of the function epilogue. Like @code{(return)}, this may also occur in
conditional jumps.
which from what you say above seems to be accurate, but rtl.def says:
/* A plain return, to be used on paths that are reached without going
through the function prologue. */
DEF_RTL_EXPR(SIMPLE_RETURN, "simple_return", "", RTX_EXTRA)
which is slightly different, and seems to be describing the pattern
more than the rtx. I think the rtl.def comment should be along the
same lines as the rtl.texi documentation.
OK with that change from a MIPS and rtl and perspective.
Richard
