[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ (part1)

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.