public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Jeff Law <law@redhat.com>, Vladimir Makarov <vmakarov@redhat.com>,
	gcc@gnu.org, 	gcc-patches <gcc-patches@gcc.gnu.org>,
	Evgeny Stupachenko <evstupac@gmail.com>,
		Richard Biener <richard.guenther@gmail.com>
Subject: Re: Enable EBX for x86 in 32bits PIC code
Date: Thu, 28 Aug 2014 13:29:00 -0000	[thread overview]
Message-ID: <CAMbmDYaqS1VLx+3MWgSXErKT7edqWkObWh+GWOxfb1U8E473Wg@mail.gmail.com> (raw)
In-Reply-To: <CAFULd4YaEDYcwJT1Dj6eqvfGkhTwQzd95o2uMiwi=VYonfVj1Q@mail.gmail.com>

2014-08-28 17:08 GMT+04:00 Uros Bizjak <ubizjak@gmail.com>:
> On Thu, Aug 28, 2014 at 2:54 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>
>>>>>> diff --git a/gcc/calls.c b/gcc/calls.c
>>>>>> index 4285ec1..85dae6b 100644
>>>>>> --- a/gcc/calls.c
>>>>>> +++ b/gcc/calls.c
>>>>>> @@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals
>>>>>> ATTRIBUTE_UNUSED,
>>>>>>       call_expr_arg_iterator iter;
>>>>>>       tree arg;
>>>>>>
>>>>>> +    if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
>>>>>> +      {
>>>>>> +       gcc_assert (pic_offset_table_rtx);
>>>>>> +       args[j].tree_value = make_tree (ptr_type_node,
>>>>>> +                                       pic_offset_table_rtx);
>>>>>> +       j--;
>>>>>> +      }
>>>>>> +
>>>>>>       if (struct_value_addr_value)
>>>>>>         {
>>>>>>         args[j].tree_value = struct_value_addr_value;
>>>>>
>>>>> So why do you need this?  Can't this be handled in the call/call_value
>>>>> expanders or what about attaching the use to CALL_INSN_FUNCTION_USAGE from
>>>>> inside ix86_expand_call?  Basically I'm not seeing the need for another
>>>>> target hook here.  I think that would significantly simply the patch as
>>>>> well.
>>>>
>>>> GOT base address become an additional implicit arg with EBX relaxed
>>>> and I handled it as all other args. I can move EBX initialization into
>>>> ix86_expand_call. Would still need some hint from target to init
>>>> pic_offset_table_rtx with proper value in the beginning of function
>>>> expand.
>>>
>>> Maybe you can you use get_hard_reg_initial_val for this?
>>
>> Actually there is no input hard reg holding GOT address.  Currently I
>> use initialization with ebx with following ebx initialization in
>> prolog_epilog pass.  But this is a temporary workaround.  It is
>> inefficient because always uses callee save reg to get GOT address.  I
>> suppose we should generate pseudo reg for pic_offset_table_rtx and
>> also set_got with this register as a destination in expand pass.
>> After register allocation set_got may be transformed into get_pc_thunk
>> call with proper hard reg.  But some target hook has to be used for
>> this.
>
> Let me expand my idea a bit. IIRC, get_hard_reg_initial_val and
> friends will automatically emit intialization of a pseudo from
> pic_offset_table_rtx hard reg. After reload, real initialization of
> pic_offset_table_rtx hard reg is emitted in pro_and_epilogue pass. I
> don't know if this works with current implementation of dynamic
> pic_offset_table_rtx selection, though.

That means you should choose some hard reg early before register
allocation to be used for PIC reg initialization.  I do not like we
have to do this and want to just generate set_got with pseudo reg and
do not involve any additional hard reg. That would look like

(insn/f 168 167 169 2 (parallel [
            (set (reg:SI 127)
                (unspec:SI [
                        (const_int 0 [0])
                    ] UNSPEC_SET_GOT))
            (clobber (reg:CC 17 flags))
        ]) test.cc:42 -1
     (expr_list:REG_CFA_FLUSH_QUEUE (nil)
        (nil)))

after expand pass.  r127 is pic_offset_table_rtx here. And after
reload it would become:

(insn/f 168 167 169 2 (parallel [
            (set (reg:SI 3 bx)
                (unspec:SI [
                        (const_int 0 [0])
                    ] UNSPEC_SET_GOT))
            (clobber (reg:CC 17 flags))
        ]) test.cc:42 -1
     (expr_list:REG_CFA_FLUSH_QUEUE (nil)
        (nil)))

And no additional actions are required on pro_and_epilogue.  Also it
simplifies analysis whether we should generate set_got at all.
Current we check hard reg is ever live which is wrong with not fixed
ebx because any usage of hard reg used to init GOT doesn't mean GOT
usage.  And with my proposed scheme unused GOT would mean DCE just
removes useless set_got.

Ilya

>
> Uros.

  reply	other threads:[~2014-08-28 13:29 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAOvf_xxsQ_oYGqNAVQ1+BW+CuD3mzebZ2xma0jpF=WfyZMCRCA@mail.gmail.com>
     [not found] ` <CAFiYyc1mFtTezkTJORmJJq+yht=qPSwiN7KDn19+bSuSdaqvMQ@mail.gmail.com>
     [not found]   ` <CAOvf_xyeVeg2oB9Xxz8RMEQ6gyfJY5whd9s4ygoAAEaMU9efnA@mail.gmail.com>
     [not found]     ` <20140707114750.GB31640@tucnak.redhat.com>
     [not found]       ` <CAMbmDYZV_fx0jxmKHhLsC2pJ7pDzuu6toEAH72izOdpq6KGyfg@mail.gmail.com>
2014-08-22 12:21         ` Ilya Enkovich
2014-08-23  1:47           ` Hans-Peter Nilsson
2014-08-25  9:25             ` Ilya Enkovich
2014-08-25 11:24               ` Hans-Peter Nilsson
2014-08-25 11:43                 ` Ilya Enkovich
2014-08-25 15:09           ` Vladimir Makarov
2014-08-26  7:49             ` Ilya Enkovich
2014-08-26  8:57               ` Ilya Enkovich
2014-08-26 15:25                 ` Vladimir Makarov
2014-08-26 21:42                   ` Ilya Enkovich
2014-08-27 20:19                     ` Vladimir Makarov
2014-08-28  8:28                       ` Ilya Enkovich
2014-08-29  6:47                         ` Ilya Enkovich
2014-09-02 14:29                           ` Vladimir Makarov
2014-09-03 20:19                           ` Vladimir Makarov
     [not found]                             ` <0EFAB2BDD0F67E4FB6CCC8B9F87D756969B3A89D@IRSMSX101.ger.corp.intel.com>
2014-09-09 16:43                               ` Vladimir Makarov
2014-09-11 19:57                                 ` Jeff Law
2014-09-23 13:54                             ` Ilya Enkovich
2014-09-23 14:23                               ` Uros Bizjak
2014-09-23 15:59                                 ` Jeff Law
2014-09-23 14:34                               ` Jakub Jelinek
2014-09-23 15:59                                 ` Petr Machata
2014-09-23 16:00                                 ` Jeff Law
2014-09-23 16:03                                   ` Jakub Jelinek
2014-09-23 16:10                                     ` Jeff Law
2014-09-24  6:56                                       ` Ilya Enkovich
2014-09-24 15:27                                         ` Jeff Law
2014-09-24 20:32                                           ` Ilya Enkovich
2014-09-24 21:20                                             ` Jeff Law
2014-09-29 11:09                                               ` Jakub Jelinek
2014-10-21 16:05                                                 ` [PATCH] Improve i?86 address delegitimization after 32-bit pic changes (PR target/63542) Jakub Jelinek
2014-10-22  2:02                                                   ` Jeff Law
2014-11-24 15:57                                                   ` H.J. Lu
2014-08-27 21:39                     ` Enable EBX for x86 in 32bits PIC code Jeff Law
2014-08-28  8:37                       ` Ilya Enkovich
2014-08-28 12:43                         ` Uros Bizjak
2014-08-28 12:54                           ` Ilya Enkovich
2014-08-28 13:08                             ` Uros Bizjak
2014-08-28 13:29                               ` Ilya Enkovich [this message]
2014-08-28 16:25                                 ` Uros Bizjak
2014-08-29 18:56                         ` Jeff Law
2014-08-25 17:30           ` Jeff Law
2014-08-28 13:01           ` Uros Bizjak
2014-08-28 13:13             ` Ilya Enkovich
2014-08-28 18:30             ` Florian Weimer
2014-08-29 18:48             ` Jeff Law
2014-08-28 18:58           ` Uros Bizjak
2014-08-29  6:51             ` Ilya Enkovich
2014-08-29 18:45             ` Jeff Law

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=CAMbmDYaqS1VLx+3MWgSXErKT7edqWkObWh+GWOxfb1U8E473Wg@mail.gmail.com \
    --to=enkovich.gnu@gmail.com \
    --cc=evstupac@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gnu.org \
    --cc=law@redhat.com \
    --cc=richard.guenther@gmail.com \
    --cc=ubizjak@gmail.com \
    --cc=vmakarov@redhat.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).