On 07/07/11 21:08, Richard Sandiford wrote:
> Richard Earnshaw <rearn...@arm.com> writes:
>> On 07/07/11 15:34, Richard Sandiford wrote:
>>> It seems a shame to have both (return) and (simple_return). You said
>>> that we need the distinction in order to cope with targets like ARM,
>>> whose (return) instruction actually performs some of the epilogue too.
>>> It feels like the load of the saved registers should really be expressed
>>> in rtl, in parallel with the return. I realise that'd prevent
>>> conditional returns though. Maybe there's no elegant way out...
>>
>> You'd still need to deal with distinct returns for shrink-wrapped code
>> when the full (return) expands to
>>
>> ldm sp, {regs..., pc}
>>
>> The shrink wrapped version would always be
>> bx lr
>
> 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 ...)))])
>
> And what I meant was: the reason we can't do that is that it would make
> conditional execution harder. But the downside is that (return) and
> (simple_return) will appear to do the same thing to register r4
> (i.e. nothing). I.e. we are to some extent going to be lying to
> the rtl optimisers.
>
Hmm, yes, that would certainly help in terms of ensuring the compiler
knew the liveness correctly. But as you say, that doesn't match a
simple-jump and that could lead to other problems.
R.
