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. I suppose we could define some sort of hook though (if the need arose). To be clear, the comment about return vs. simple_return was really just musing about something that seemed a bit unclean, especially on targets like MIPS where the two instructions actually do the same thing. It also makes it harder to have partial prologues in future (do we add a third return code for that?). I don't think it's a reason to reject the change though. An alternative might be to add an rtx operand to return that gives a prologue number (again with the hook mentioned above being defined if we ever need it). That'd be slightly more general, and would allow targets to ignore it if it doesn't matter. Richard
