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
>
next prev parent 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).