From: Christoph Lameter <cl@linux-foundation•org>
To: Andi Kleen <andi@firstfloor•org>
Cc: Rusty Russell <rusty@rustcorp•com.au>,
Stephen Rothwell <sfr@canb•auug.org.au>,
linux-next@vger•kernel.org, Mike Travis <travis@sgi•com>,
Ingo Molnar <mingo@elte•hu>, Richard Henderson <rth@twiddle•net>,
akpm@linux-foundation•org
Subject: Re: linux-next: manual merge of the rr tree
Date: Thu, 8 Jan 2009 16:21:32 -0600 (CST) [thread overview]
Message-ID: <Pine.LNX.4.64.0901081539360.14124@quilx.com> (raw)
In-Reply-To: <20090108214908.GJ496@one.firstfloor.org>
On Thu, 8 Jan 2009, Andi Kleen wrote:
> On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> > This also then means that RELOC_HIDE can simply be pointer arithmetic on
> > non PPC, right?
>
> No, the C standard and the gcc optimizer are the same on all architectures.
The wrapping is okay on platforms that use straight 2 complement without
additional tricks in high bits. Some platforms do not wrap.
No need to stop the cc optimizer from optimizing pointer addition there.
The C compiler can generate more effective code if we do not go through
this asm segment. See how RELOC_HIDE is defined for the icc and
in include/linux/gcc.h.
Also: Would it not be better to rename RELOC_HIDE. To
ADD_POINTER_OFFSET_BEYOND_OBJECT_BOUNDARY or so?
What are the following uses of RELOC_HIDE to add a zero offset. Certainly
they have nothing to do with wrapping.
arch/mips/include/asm/page.h:#define __pa_symbol(x)
__pa(RELOC_HIDE((unsigned long)(x), 0))
arch/sh/include/asm/system.h: struct pt_regs *regs = RELOC_HIDE(&__regs,
0); \
arch/x86/include/asm/page_32.h:#define __phys_reloc_hide(x)
RELOC_HIDE((x), 0)
Guess we assume that GCC is passing some magic with a pointer that is
not lost when casting it?
What kind of magical properties are these? Address invalidation is messed
up in gcc and just icc does it right?
next prev parent reply other threads:[~2009-01-08 22:22 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-05 3:32 linux-next: manual merge of the rr tree Stephen Rothwell
2009-01-05 6:57 ` Rusty Russell
2009-01-05 12:47 ` Ingo Molnar
2009-01-06 8:51 ` Rusty Russell
2009-01-06 9:20 ` Ingo Molnar
2009-01-06 13:13 ` Mike Travis
2009-01-06 13:19 ` Ingo Molnar
2009-01-06 14:21 ` Mike Travis
2009-01-06 14:59 ` Ingo Molnar
2009-01-07 2:46 ` Rusty Russell
2009-01-05 15:29 ` Christoph Lameter
2009-01-06 1:04 ` Rusty Russell
2009-01-06 15:05 ` Christoph Lameter
2009-01-07 2:47 ` Rusty Russell
2009-01-07 16:11 ` Christoph Lameter
2009-01-07 17:20 ` Andi Kleen
2009-01-07 19:01 ` Christoph Lameter
2009-01-08 20:48 ` Andi Kleen
2009-01-08 20:50 ` Andrew Morton
2009-01-08 21:15 ` Christoph Lameter
2009-01-08 21:49 ` Andi Kleen
2009-01-08 22:21 ` Christoph Lameter [this message]
2009-01-08 22:25 ` David Miller
2009-01-09 14:42 ` Christoph Lameter
2009-01-09 22:54 ` David Miller
2009-01-05 19:46 ` Mike Travis
2009-01-05 8:41 ` Rusty Russell
2009-01-06 3:46 ` Stephen Rothwell
2009-01-06 13:26 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2009-01-09 1:53 Stephen Rothwell
2009-01-06 3:11 Stephen Rothwell
2008-12-29 7:51 Stephen Rothwell
2008-12-29 7:47 Stephen Rothwell
2008-12-29 8:02 ` Stephen Rothwell
2008-12-22 6:32 Stephen Rothwell
2008-12-22 7:58 ` Rusty Russell
2008-12-22 8:45 ` Mark McLoughlin
2009-01-04 23:30 ` Stephen Rothwell
2009-01-05 4:36 ` Greg KH
2009-01-05 5:56 ` Stephen Rothwell
2008-12-16 5:29 Stephen Rothwell
2008-12-15 6:15 Stephen Rothwell
2008-11-24 3:20 Stephen Rothwell
2008-11-20 3:24 Stephen Rothwell
2008-11-20 4:28 ` Rusty Russell
2008-11-14 4:13 Stephen Rothwell
2008-11-14 4:20 ` Stephen Rothwell
2008-11-14 4:30 ` David Miller
2008-11-14 4:36 ` Stephen Rothwell
2008-11-14 4:41 ` David Miller
2008-11-14 5:06 ` Stephen Rothwell
2008-11-14 6:42 ` David Miller
2008-11-15 22:32 ` Rusty Russell
2008-11-17 2:57 ` David Miller
2008-11-07 5:01 Stephen Rothwell
2008-10-29 4:28 Stephen Rothwell
2008-10-29 4:33 ` Stephen Rothwell
2008-10-29 22:42 ` Rusty Russell
2008-10-28 2:55 Stephen Rothwell
2008-10-28 7:19 ` Heiko Carstens
2008-10-28 7:24 ` Stephen Rothwell
2008-10-27 3:32 Stephen Rothwell
2008-10-24 2:21 Stephen Rothwell
2008-10-23 4:12 Stephen Rothwell
2008-10-23 5:16 ` Rusty Russell
2008-10-23 12:26 ` Rusty Russell
2008-10-23 12:50 ` Mike Travis
2008-10-23 4:01 Stephen Rothwell
2008-10-23 7:17 ` Peter Zijlstra
2008-10-23 13:32 ` Rusty Russell
2008-10-23 3:56 Stephen Rothwell
2008-10-23 12:25 ` Rusty Russell
2008-09-12 21:53 Stephen Rothwell
2008-07-28 3:16 Stephen Rothwell
2008-07-28 3:13 Stephen Rothwell
2008-07-28 3:09 Stephen Rothwell
2008-07-22 4:58 Stephen Rothwell
2008-07-22 14:21 ` Mike Travis
2008-07-16 8:15 Stephen Rothwell
2008-07-17 5:46 ` Max Krasnyansky
2008-07-18 4:31 ` Rusty Russell
2008-07-14 6:52 Stephen Rothwell
2008-07-03 5:03 Stephen Rothwell
2008-07-03 5:56 ` Ingo Molnar
2008-07-03 8:07 ` Stephen Rothwell
2008-07-03 8:19 ` Ingo Molnar
2008-07-04 0:45 ` Rusty Russell
2008-07-04 0:29 ` Rusty Russell
2008-06-25 6:27 Stephen Rothwell
2008-06-25 6:38 ` Christian Borntraeger
2008-06-25 15:23 ` Stephen Rothwell
2008-06-25 6:27 Stephen Rothwell
2008-06-25 7:47 ` Ingo Molnar
2008-06-25 8:33 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0901081539360.14124@quilx.com \
--to=cl@linux-foundation$(echo .)org \
--cc=akpm@linux-foundation$(echo .)org \
--cc=andi@firstfloor$(echo .)org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=rth@twiddle$(echo .)net \
--cc=rusty@rustcorp$(echo .)com.au \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=travis@sgi$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox