lkml.org 
[lkml]   [2001]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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