[PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info

[Anton Blanchard]

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