On 07/11/11 13:08, Richard Sandiford wrote: > Bernd Schmidt <ber...@codesourcery.com> writes: >> On 07/07/11 22:08, Richard Sandiford wrote: >>> Sure, I understand that returns does more than return on ARM. >>> What I meant was: we'd normally want that other stuff to be >>> expressed in rtl alongside the (return) rtx. E.g. something like: >>> >>> (parallel >>> [(return) >>> (set (reg r4) (mem (plus (reg sp) (const_int ...)))) >>> (set (reg r5) (mem (plus (reg sp) (const_int ...)))) >>> (set (reg sp) (plus (reg sp) (const_int ...)))]) >> >> I've thought about it some more. Isn't this just a question of >> definitions? Much like we implicitly clobber call-used registers for a >> CALL rtx, we might as well define RETURN to restore the intersection >> between regs_ever_live and call-saved regs? This is what its current >> usage implies, but I guess it's never been necessary to spell it out >> explicitly since we don't optimize across branches to the exit block. > > I don't think we could assume that for all targets. On ARM, (return) > restores registers, but on many targets it's done separately.
An instruction that does not do this should then use simple_return, which has the appropriate definition (just return, nothing else). For most ports I expect there is no difference, since HAVE_return tends to have a guard that requires no epilogue (as the documentation suggests should be the case). Bernd
