public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carrot Wei <carrot@google.com>
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: Andrew Haley <aph@redhat.com>,
	gcc@gcc.gnu.org,         Richard Earnshaw <rearnsha@arm.com>,
	        Paul Brook <paul@codesourcery.com>,
	nickc@redhat.com
Subject: Re: Where can I put the optimization of got for arm back end at?
Date: Fri, 02 Apr 2010 04:06:00 -0000	[thread overview]
Message-ID: <m2m7587b291004012106z21c82ebeo6ed3269a0fa07a04@mail.gmail.com> (raw)
In-Reply-To: <h2t571f6b511004011331x5b45d8f6y7530d23b5614e87a@mail.gmail.com>

This is really a good question!

Consider the requirement of this optimization.

1. There should be at least 2 methods to load a global variable's
address from GOT. Usually it means using different relocation types.

2. By default all global variables access use the same one method.

3. In some cases (less than X global variables access) method A is
better, in other cases method B is better.

With these constraints a simplify_GOT optimization pass is applicable.
But these constraints are too weak. The new optimization pass nearly
can do nothing except a call to target specific hook. I suspect such a
pass is acceptable.

We can also add more constraints:

4. If we can restrict method A as following: first load the base
address of GOT into a register pic_reg, then the real global
variable's address is loaded as
            load offset_reg, the offset from GOT base to the GOT entry
            load address, [pic_reg + offset_reg]

With this constraint the new pass knows there is a special register
pic_reg, it can look for and count all usage of pic_reg. If all usages
are method A and the count is more than the target specific threshold,
then the usages can be rewritten as method B. The method detection and
rewritten should be target specific.

I don't know how other targets handle global address access with
-fpic. And how many targets satisfy these 4 constraints.

thanks
Guozhi

On Fri, Apr 2, 2010 at 4:31 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Thu, Apr 1, 2010 at 8:10 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 28/03/10 15:45, Carrot Wei wrote:
>>> Hi
>>>
>>> The detailed description of the optimization is at
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129. This is an ARM
>>> specific optimization.
>>>
>>> This optimization uses one less register (the register hold the GOT
>>> base), to get this beneficial the ideal place for it should be before
>>> register allocation.
>>>
>>> Usually expand pass generates instructions to load global variable's
>>> address from GOT entry for each access of the global variable. Later
>>> cse/gcse passes can remove many of them. In order to precisely model
>>> the cost, this optimization should be put after some cse/gcse passes.
>>>
>>> So what is the best place for this optimization? Is there any existed
>>> pass can be enhanced with this optimization? Or should I add a new
>>> pass?
>>
>> The obvious place is machine-dependent reorg, which is a very late pass.
>
> Yes, and after register allocation, i.e. too late for Guozhi.
>
> Basically there is no place right now to stuff a pass like that.
> Question is: Is this optimization really, reallyreallyreally so target
> specific that a target-independent pass is not the better option?
>
> Ciao!
> Steven
>

  reply	other threads:[~2010-04-02  4:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-28 21:00 Carrot Wei
2010-04-01 18:11 ` Andrew Haley
2010-04-01 20:31   ` Steven Bosscher
2010-04-02  4:06     ` Carrot Wei [this message]
     [not found]       ` <l2z5885251a1004050624h1237ec10z2a0bf34b7ba91d2c@mail.gmail.com>
2010-04-06 13:38         ` Carrot Wei

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=m2m7587b291004012106z21c82ebeo6ed3269a0fa07a04@mail.gmail.com \
    --to=carrot@google.com \
    --cc=aph@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=nickc@redhat.com \
    --cc=paul@codesourcery.com \
    --cc=rearnsha@arm.com \
    --cc=stevenb.gcc@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).