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? -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
