Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281044AbRKKMlZ>; Sun, 11 Nov 2001 07:41:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281047AbRKKMlO>; Sun, 11 Nov 2001 07:41:14 -0500
Received: from samba.sourceforge.net ([198.186.203.85]:17162 "HELO
	lists.samba.org") by vger.kernel.org with SMTP id <S281044AbRKKMlH>;
	Sun, 11 Nov 2001 07:41:07 -0500
Date: Sun, 11 Nov 2001 23:36:11 +1100
From: Anton Blanchard <anton@samba.org>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: "David S. Miller" <davem@redhat.com>, jakub@redhat.com, bcrl@redhat.com,
        torvalds@transmeta.com, alan@lxorguk.ukuu.org.uk, arjanv@redhat.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] take 2 of the tr-based current
Message-ID: <20011111233611.A7409@krispykreme>
In-Reply-To: <20011108211143.A4797@redhat.com> <20011109041327.T4087@devserv.devel.redhat.com> <3BEBEE0B.BA1FD7EE@colorfullife.com> <20011109.070312.88700201.davem@redhat.com> <3BEBF730.86CAE1CC@colorfullife.com> <20011111110107.A4064@krispykreme> <3BEE4C04.4040406@colorfullife.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3BEE4C04.4040406@colorfullife.com>
User-Agent: Mutt/1.3.23i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


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/