This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/6] Shrink-wrapping


On 07/11/11 13:08, Richard Sandiford wrote:
> Bernd Schmidt <bernds@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]