Subject: Re: linux-next: manual merge of the rr tree

From: Christoph Lameter <[email-masked]>
Date: Thu, 8 Jan 2009 16:21:32 -0600 (CST)

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?