public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Hildner <christian.hildner@hob.de>
To: linux-ia64@vger.kernel.org
Subject: Re: optimize __gp location
Date: Mon, 24 Jan 2005 13:44:22 +0000	[thread overview]
Message-ID: <41F4FBB6.2040406@hob.de> (raw)
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB50589FCE9@scsmsx401.amr.corp.intel.com>

Keith Owens schrieb:

>On Mon, 24 Jan 2005 08:51:17 +0100, 
>Christian Hildner <christian.hildner@hob.de> wrote:
>  
>
>>Chen, Kenneth W schrieb:
>>    
>>
>>>Can we position the __gp somewhat more optimally, to cover more of these
>>>symbols? Something like the following patch would make all of them fall
>>>into the 22-bit immediate offset relative to gp.
>>>
>>>      
>>>
>>Did you have benchmarks? Or at least a comparison of the resulting code 
>>size. The code size should shrink when more items can be addressed 
>>directly. Furthermore the code size should be a good indicator for the 
>>performance gain you could achive.
>>    
>>
>
>The IA64 ABI supports link time rewriting of instructions if the linker
>can determine that the field being loaded can be access via __gp
>instead of via the linkage offset table.  One of the restrictions of
>link time rewriting is that the code offsets cannot change, which means
>that the code size cannot change either.  This code snippet will result
>in two different run time sequences, depending on whether jiffies can
>be referenced via __gp or not.
>
>    addl r20=0,r1;;	// LTOFF22X  jiffies
>    ld8 r16=[r20];;	// LDXMOV    jiffies
>    ld8.acq r23=[r16]	// value of jiffies
>
>When jiffies is within 22 bit range of __gp, the linker writes the
>sequence as
>
>    addl r20=offset_of(jiffies,__gp),r1;;
>    mov r16=r20;;
>    ld8.acq r23=[r16]	// value of jiffies
>
Is there a restriction to not rewrite to

    addl r16=offset_of(jiffies,__gp),r1;;
    ld8.acq r23=[r16]	// value of jiffies
    nop.i 0

because that would save at least one cycle and would make bundling easier (dependend of additional instructions, of course).

Christian



  parent reply	other threads:[~2005-01-24 13:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 23:22 optimize __gp location Chen, Kenneth W
2005-01-22  1:02 ` Keith Owens
2005-01-22  1:02 ` Luck, Tony
2005-01-22  2:20 ` Chen, Kenneth W
2005-01-22  3:09 ` Keith Owens
2005-01-24  7:51 ` Christian Hildner
2005-01-24 13:22 ` Keith Owens
2005-01-24 13:29   ` Matthew Wilcox
2005-01-24 13:44 ` Christian Hildner [this message]
2005-01-24 15:32 ` Keith Owens
2005-01-24 17:51 ` David Mosberger
2005-01-24 17:53 ` David Mosberger
2005-01-25  7:30 ` Christian Hildner
2005-01-25 19:44 ` Chen, Kenneth W
2005-01-25 19:51 ` David Mosberger
2005-01-25 19:57 ` Chen, Kenneth W
2005-01-25 20:01 ` David Mosberger

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=41F4FBB6.2040406@hob.de \
    --to=christian.hildner@hob.de \
    --cc=linux-ia64@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox