Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes:
> On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
>> Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> writes:
>>
>> > ARMv6 and greater introduced a new instruction ("bx") which can be used
>> > to return from function calls. Recent CPUs perform better when the
>> > "bx lr" instruction is used rather than the "mov pc, lr" instruction,
>> > and this sequence is strongly recommended to be used by the ARM
>> > architecture manual (section A.4.1.1).
>> >
>> > We provide a new macro "ret" with all its variants for the condition
>> > code which will resolve to the appropriate instruction.
>>
>> When the source register is not "lr" the name "ret" is a misnomer since
>> only the "bx lr" instruction is predicted as a function return. The
>> "bx" instruction with other source registers uses the normal prediction
>> mechanisms, leaving the return stack alone, and should not be used for
>> function returns. Any code currently using another register to return
>> from a function should probably be modified to use lr instead, unless
>> there are special reasons for doing otherwise. If code jumping to an
>> address in a non-lr register is not a return, using the "ret" name will
>> make for some rather confusing reading.
>>
>> I would suggest either using a more neutral name than "ret" or adding an
>> alias to be used for non-return jumps so as to make the intent clearer.
>
> If you read the patch, the branches which are changed are those which
> do indeed return in some way. There are those which do this having
> moved lr to a different register.
The patch is huge, and it wasn't obvious (to me) from the diff context
what the non-lr jumps were doing.
> As you point out, "bx lr" /may/ be treated specially (I've actually been
Most, if not all, Cortex-A cores do this according the public TRMs.
They also do the same thing for "mov pc, lr" so there will probably be
no performance gain from this change. It's still a good idea though,
since we don't know what future cores will do.
> discussing this with Will Deacon over the last couple of days, who has
> also been talking to the hardware people in ARM, and Will is happy with
> this patch as in its current form.) This is why I've changed all
> "mov pc, reg" instructions which return in some way to use this macro,
> and left others (those which are used to call some function and return
> back to the same point) alone.
In that case the patch should be fine. Your patch description didn't
make it clear that only actual returns were being changed.
--
Måns Rullgård
mans@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
