Messages in this thread | | | Date | Sun, 11 Nov 2001 23:36:11 +1100 | From | Anton Blanchard <> | Subject | Re: [PATCH] take 2 of the tr-based current |
| |
Hi,
> 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).
Anton
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(); schedule(); 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |