All of lore.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 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.