On Wed, May 06, 2026 at 09:17:53AM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2026 at 05:48:32PM +0200, Christophe Leroy (CS GROUP) wrote:
> > bclr (which is the return INSN_RETURN) has type 19
> >
> > By the way you can have a look at
> > https://patchwork.ozlabs.org/project/linuxppc-dev/patch/bfa8364da047d8610a09458a1cd924a0566aedbb.1736955567.git.christophe.le...@csgroup.eu/
>
> That is indeed more; isn't bcl something like COND_CALL ? (another one
> of them things we don't have).
Yeah, all of bc[l][a] are conditional branches. "a" (AA=1) means the
branch target is an absolute address (in the top or bottom 8kB of the
address space), and "l" (LK=1) means set LR to the NIA ("next
instruction address") before doing the branch.
The BO field describes the condition. 0x14 means "always". (But there
also are primary opcodes for b[l][a], with a bigger target field, 24
bits instead of the 14 bits of bc[l][a]; you do not have the BI and BO
fields then of course) ("branch index" and "branch option" btw).
> > That patch has all the objtool decoding. By the way objtool is missing a
> > INSN_CONDITIONAL_RETURN, also see
> > https://patchwork.ozlabs.org/project/linuxppc-dev/patch/537e5d8f181b1f1c2b8918f1aefa1dba3f972c03.1736955567.git.christophe.le...@csgroup.eu/
>
> Right, that is not something x86 has, but I don't see a reason we can't
> add that. With return thunks, Clang (and I've heard GCC is also
> considering this) does something very close to conditional return.
A conditional blr does not map well to most compiled languages. It is
nice for hand-written machine code though :-)
For compiled code you almost always want to make some of the associated
stack frame maintenance conditional as well (because the ABIs require
this, if nothing else!)
I guess we could add some special-case stuff for it, maybe a peephole,
but we probably would have to write a whole new pass for it, stuff with
branch instructions always requires special checks :-p
> That way we do the return checks, but don't terminate the control flow.
> After all, when the condition is taken, we had better have the stack
> frame in the same state etc.
Ugh, mixed abstractions again :-(
Segher
