Hi Alan,

Right.  This is really an rs6000 backend bug.  We describe one of the
indirect calls that go wrong here as

(call_insn 108 107 109 13 (parallel [
            (set (reg:DI 3 3)
                (call (mem:SI (reg:DI 288) [0 *_67 S4 A8])
                    (const_int 64 [0x40])))
            (use (mem:DI (plus:DI (reg/f:DI 287 [ ops_44(D)->update ])
                        (const_int 8 [0x8])) [0  S8 A8]))
            (set (reg:DI 2 2)
                (mem/v/c:DI (plus:DI (reg/f:DI 1 1)
                        (const_int 40 [0x28])) [0  S8 A8]))
            (clobber (reg:DI 65 lr))
        ]) net/core/skbuff.c:2085 680 {*call_value_indirect_aixdi}
	<notes and arg uses omitted for clarity>
)

Notice that the RTL contains a "parallel".  As you might guess, gcc
treats the vector of expressions inside the square brackets of the
parallel as happening "in parallel".  Meaning that as far as gcc is
concerned the toc restore part (third element) happens at the same
time as the call (first element).  So if gcc replaces (reg:DI 1) in
the toc restore with some other register known to have the same value
*before* the call, gcc's RTL analysis will conclude that such a
replacement is valid.

Thanks for looking into this. Does that mean we were just getting lucky
with the previous version:

static inline struct thread_info *current_thread_info(void)
{
        register unsigned long sp asm("r1");

        return (struct thread_info *)(sp & ~(THREAD_SIZE-1));
}
 
ie a static register asm instead of a global one. If so the safest fix
for now might be to just eat the overead of a register move:

static inline struct thread_info *current_thread_info(void)
{
        unsigned long sp;

        asm("mr %0,1": "=r"(sp));
        return (struct thread_info *)(sp & ~(THREAD_SIZE-1));
}

Anton