[lkml]   [2001]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] take 2 of the tr-based current


    > But the function called schedule - mustn't gcc assume that schedule
    > writes into global variables?
    > As far as I can see that sounds like a gcc bug.

    Yes gcc knows we need to reload across a function call, but it also
    knows that the get_cpu function uses no global variables.

    > Could you try how many get_cpu calls are generated by the attached testapp?

    I changed the code a bit so that get_cpu() is now inline - this
    represents our situation better. I think it is valid for gcc to cache
    get_cpu across a function call in the below example because it knows
    that get_cpu does not refer to any global variables.

    I brought it up in case gcc optimises your get_tr the same way (I cant
    remember what the operand constraints on it were now, if it was only a
    register then you might see it).

    (The disassembly of the below has only one mfspr and it caches the
    result across schedule).


    int cpu;

    static void schedule(void);

    static inline int get_cpu(void) __attribute__((pure));
    static inline int get_cpu(void)
    int ret;
    __asm__ ("mfspr %0, 0x113"
    : "=r" (ret)

    return ret;

    int main(void)
    int cpu1, cpu2, cpu3, cpu4;
    cpu1 = get_cpu();
    cpu2 = get_cpu();
    cpu3 = get_cpu();
    cpu4 = get_cpu();
    printf("the cpu values were %d %d %d %d.\n",
    cpu1, cpu2, cpu3, cpu4);
    return 0;

    static void schedule(void)
    cpu = 2;
    printf("schedule called .\n");
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:13    [W:3.096 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site