public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Jeff Law <law@redhat.com>
Cc: Jakub Jelinek <jakub@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>,
	Uros Bizjak <ubizjak@gmail.com>,
		Petr Machata <pmachata@redhat.com>
Subject: Re: Enable EBX for x86 in 32bits PIC code
Date: Wed, 24 Sep 2014 20:32:00 -0000	[thread overview]
Message-ID: <CAMbmDYbnCxvLDz7gzXj1H7uwhDNOCHpq2G9AU5i4bUJG_x0hLQ@mail.gmail.com> (raw)
In-Reply-To: <5422E2E3.807@redhat.com>

2014-09-24 19:27 GMT+04:00 Jeff Law <law@redhat.com>:
> On 09/24/14 00:56, Ilya Enkovich wrote:
>>
>> 2014-09-23 20:10 GMT+04:00 Jeff Law <law@redhat.com>:
>>>
>>> On 09/23/14 10:03, Jakub Jelinek wrote:
>>>>
>>>>
>>>> On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
>>>>>
>>>>>
>>>>> On 09/23/14 08:34, Jakub Jelinek wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
>>>>>>>
>>>>>>>
>>>>>>> use fixed EBX at least until we make sure pseudo PIC doesn't harm
>>>>>>> debug
>>>>>>> info generation.  If we have such option then gcc.target/i386/pic-1.c
>>>>>>> and
>>>>>>
>>>>>>
>>>>>>
>>>>>> For debug info, it seems you are already handling this in
>>>>>> delegitimize_address target hook, I'd suggest just building some very
>>>>>> large
>>>>>> shared library at -O2 -g -fpic on i?86 and either look at the
>>>>>> sizes of .debug_info/.debug_loc sections with/without the patch,
>>>>>> or use the locstat utility from elfutils (talk to Petr Machata if
>>>>>> needed).
>>>>>
>>>>>
>>>>> Can't hurt, but I really don't see how changing from a fixed to an
>>>>> allocatable register is going to muck up debug info in any significant
>>>>> way.
>>>>
>>>>
>>>>
>>>> What matters is if the delegitimize_address target hook is as efficient
>>>> in
>>>> delegitimization as before.  E.g. if it previously matched only when
>>>> seeing
>>>> %ebx + gotoff or similar, and wouldn't match anything now, some vars
>>>> could
>>>> have debug locations including UNSPEC and be dropped on the floor.
>>>
>>>
>>> Ah, yea, that makes sense.
>>>
>>> jeff
>>
>>
>>
>> After register allocation we have no idea where GOT address is and
>> therefore delegitimize_address target hook becomes less efficient and
>> cannot remove UNSPECs. That's what I see now when build GCC with patch
>> applied:
>
> In theory this shouldn't be too hard to fix.
>
> I haven't looked at the code, but it might be something looking explicitly
> for ebx by register #, or something similar.  Which case within
> delegitimize_address isn't firing as it should after your changes?

It is the case I had to fix:

@@ -14415,7 +14433,8 @@ ix86_delegitimize_address (rtx x)
         ...
         movl foo@GOTOFF(%ecx), %edx
         in which case we return (%ecx - %ebx) + foo.  */
-      if (pic_offset_table_rtx)
+      if (pic_offset_table_rtx
+         && (!reload_completed || !ix86_use_pseudo_pic_reg ()))
         result = gen_rtx_PLUS (Pmode, gen_rtx_MINUS (Pmode, copy_rtx (addend),
                                                     pic_offset_table_rtx),
                               result);

Originally if there is a UNSPEC_GOTOFFSET but no EBX usage then we
just remove this UNSPEC and substract EBX value.  With pseudo PIC reg
we should use PIC register instead of EBX but it is unclear what to
use after register allocation.

Ilya

>
> jeff
>

  reply	other threads:[~2014-09-24 20:32 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 [this message]
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
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=CAMbmDYbnCxvLDz7gzXj1H7uwhDNOCHpq2G9AU5i4bUJG_x0hLQ@mail.gmail.com \
    --to=enkovich.gnu@gmail.com \
    --cc=evstupac@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gnu.org \
    --cc=jakub@redhat.com \
    --cc=law@redhat.com \
    --cc=pmachata@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).