All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Ingo Molnar <mingo@elte.hu>,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	andi@firstfloor.org, ak@linux.intel.com, sfr@canb.auug.org.au,
	travis@sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/8] compiler-gcc.h: add more comments to RELOC_HIDE
Date: Mon, 19 Jan 2009 08:30:33 -0800	[thread overview]
Message-ID: <4974AAA9.2000406@twiddle.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0901161433410.27177@quilx.com>

Christoph Lameter wrote:
> On Thu, 15 Jan 2009, Richard Henderson wrote:
> 
>> I didn't explore the space of possible solutions, merely gave Rusty a solution
>> that I knew would work, and would never fail because the compiler would never
>> look through the asm.
>>
>> I wouldn't be surprised if the compiler thought "(long)&foo - large_constant"
>> could be put back together into a small-data relocation, simply because at the
>> level at which that optimization is performed, we've thrown away type data
>> like long and void*; we only have modes.
> 
> We are talking about
> 
> (long)&foo + long_variable
> 
> Are you saying that the compiler will be ignoring the high bits in
> variable because of the size of foo?

No, I'm saying that all those high bits will be passed along and won't
fit in the 16-bit relocation that'll come out of the assembler, leading
to a hard linker error.

> It looks like its useless and more an indication of either a broken
> compiler or wrong assumptions about the compiler. Removing RELOC_HIDE
> should allow the compiler to freely optimize the per cpu address
> calculations.

Something I'm pretty sure we don't want the compiler to be able to do.


r~

  reply	other threads:[~2009-01-19 16:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200901100040.n0A0eruc013680@imap1.linux-foundation.org>
     [not found] ` <200901102211.45603.rusty@rustcorp.com.au>
2009-01-10 12:29   ` [patch 2/8] compiler-gcc.h: add more comments to RELOC_HIDE Ingo Molnar
2009-01-12 17:33     ` Christoph Lameter
     [not found]       ` <200901151227.27935.rusty@rustcorp.com.au>
2009-01-15  3:33         ` Linus Torvalds
2009-01-15 19:19           ` Christoph Lameter
2009-01-15 22:44             ` Andi Kleen
2009-01-15 20:29         ` Christoph Lameter
2009-01-15 23:15           ` Richard Henderson
2009-01-16 20:37             ` Christoph Lameter
2009-01-19 16:30               ` Richard Henderson [this message]
2009-01-21 13:50                 ` Christoph Lameter

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=4974AAA9.2000406@twiddle.net \
    --to=rth@twiddle.net \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    --cc=travis@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.