diff mbox

[PR,rtl-optimization/79286] Drop may_trap_p exception to testing dominance in update_equiv_regs

Message ID AM4PR0701MB216212D47DFF1723ED41F7E6E4120@AM4PR0701MB2162.eurprd07.prod.outlook.com
State New
Headers show

Commit Message

Bernd Edlinger April 29, 2017, 7:06 a.m. UTC 
On 04/28/17 20:46, Jeff Law wrote:
> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:

>>>

>>

>> Yes I agree, that is probably not worth it.  So I could try to remove

>> the special handling of PIC+const and see what happens.

>>

>> However the SYMBOL_REF_FUNCTION_P is another story, that part I would

>> like to keep: It happens quite often, already w/o -fpic that call

>> statements are using SYMBOL_REFs to ordinary (not weak) function

>> symbols, and may_trap returns 1 for these call statements wihch is IMHO

>> wrong.

> Hmm, thinking more about this, wasn't the original case a PIC referrence

> for something like &x[BIGNUM].

>

> Perhaps we could consider a PIC reference without other arithmetic as

> safe.  That would likely pick up the SYMBOL_REF_FUNCTION_P case you want

> as well good deal many more PIC references as non-trapping.

>


Yes, I like this idea.

I tried to compile openssl with -m32 -fpic as an example, and counted
how often the mem[pic+const] is hit: that was 2353 times, all kind of
object refs.

Then I tried your idea, and only 54 unhandled pic refs remained, all of
them looking like this:

(plus:SI (reg:SI 107)
     (const:SI (plus:SI (unspec:SI [
                     (symbol_ref:SI ("bf_init") [flags 0x2] <var_decl 
0x2ac00f7bac60 bf_init>)
                 ] UNSPEC_GOTOFF)
             (const_int 4164 [0x1044]))))

I believe that is a negligible fall out from such a big code base.

Although the pic references do no longer reach the
SYMBOL_REF_FUNCTION_P in this version of the patch, I still see
that happening without -fpic option, so I left it as is.


Attached is the new version of my patch.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.

Comments

Bernd Edlinger May 12, 2017, 4:48 p.m. UTC | #1 
Ping...

On 04/29/17 09:06, Bernd Edlinger wrote:
> On 04/28/17 20:46, Jeff Law wrote:

>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:

>>>>

>>>

>>> Yes I agree, that is probably not worth it.  So I could try to remove

>>> the special handling of PIC+const and see what happens.

>>>

>>> However the SYMBOL_REF_FUNCTION_P is another story, that part I would

>>> like to keep: It happens quite often, already w/o -fpic that call

>>> statements are using SYMBOL_REFs to ordinary (not weak) function

>>> symbols, and may_trap returns 1 for these call statements wihch is IMHO

>>> wrong.

>> Hmm, thinking more about this, wasn't the original case a PIC referrence

>> for something like &x[BIGNUM].

>>

>> Perhaps we could consider a PIC reference without other arithmetic as

>> safe.  That would likely pick up the SYMBOL_REF_FUNCTION_P case you want

>> as well good deal many more PIC references as non-trapping.

>>

>

> Yes, I like this idea.

>

> I tried to compile openssl with -m32 -fpic as an example, and counted

> how often the mem[pic+const] is hit: that was 2353 times, all kind of

> object refs.

>

> Then I tried your idea, and only 54 unhandled pic refs remained, all of

> them looking like this:

>

> (plus:SI (reg:SI 107)

>     (const:SI (plus:SI (unspec:SI [

>                     (symbol_ref:SI ("bf_init") [flags 0x2] <var_decl

> 0x2ac00f7bac60 bf_init>)

>                 ] UNSPEC_GOTOFF)

>             (const_int 4164 [0x1044]))))

>

> I believe that is a negligible fall out from such a big code base.

>

> Although the pic references do no longer reach the

> SYMBOL_REF_FUNCTION_P in this version of the patch, I still see

> that happening without -fpic option, so I left it as is.

>

>

> Attached is the new version of my patch.

>

> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.

> Is it OK for trunk?

>

>

> Thanks

> Bernd.
Bernd Edlinger June 1, 2017, 4 p.m. UTC | #2 
Ping...

On 05/12/17 18:48, Bernd Edlinger wrote:
> Ping...

> 

> On 04/29/17 09:06, Bernd Edlinger wrote:

>> On 04/28/17 20:46, Jeff Law wrote:

>>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:

>>>>>

>>>>

>>>> Yes I agree, that is probably not worth it.  So I could try to remove

>>>> the special handling of PIC+const and see what happens.

>>>>

>>>> However the SYMBOL_REF_FUNCTION_P is another story, that part I would

>>>> like to keep: It happens quite often, already w/o -fpic that call

>>>> statements are using SYMBOL_REFs to ordinary (not weak) function

>>>> symbols, and may_trap returns 1 for these call statements wihch is IMHO

>>>> wrong.

>>> Hmm, thinking more about this, wasn't the original case a PIC referrence

>>> for something like &x[BIGNUM].

>>>

>>> Perhaps we could consider a PIC reference without other arithmetic as

>>> safe.  That would likely pick up the SYMBOL_REF_FUNCTION_P case you want

>>> as well good deal many more PIC references as non-trapping.

>>>

>>

>> Yes, I like this idea.

>>

>> I tried to compile openssl with -m32 -fpic as an example, and counted

>> how often the mem[pic+const] is hit: that was 2353 times, all kind of

>> object refs.

>>

>> Then I tried your idea, and only 54 unhandled pic refs remained, all of

>> them looking like this:

>>

>> (plus:SI (reg:SI 107)

>>     (const:SI (plus:SI (unspec:SI [

>>                     (symbol_ref:SI ("bf_init") [flags 0x2] <var_decl

>> 0x2ac00f7bac60 bf_init>)

>>                 ] UNSPEC_GOTOFF)

>>             (const_int 4164 [0x1044]))))

>>

>> I believe that is a negligible fall out from such a big code base.

>>

>> Although the pic references do no longer reach the

>> SYMBOL_REF_FUNCTION_P in this version of the patch, I still see

>> that happening without -fpic option, so I left it as is.

>>

>>

>> Attached is the new version of my patch.

>>

>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.

>> Is it OK for trunk?

>>

>>

>> Thanks

>> Bernd.
Jeff Law June 23, 2017, 4:35 a.m. UTC | #3 
On 04/29/2017 01:06 AM, Bernd Edlinger wrote:
> On 04/28/17 20:46, Jeff Law wrote:
>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>> Yes I agree, that is probably not worth it.  So I could try to remove
>>> the special handling of PIC+const and see what happens.
>>>
>>> However the SYMBOL_REF_FUNCTION_P is another story, that part I would
>>> like to keep: It happens quite often, already w/o -fpic that call
>>> statements are using SYMBOL_REFs to ordinary (not weak) function
>>> symbols, and may_trap returns 1 for these call statements wihch is IMHO
>>> wrong.
>> Hmm, thinking more about this, wasn't the original case a PIC referrence
>> for something like &x[BIGNUM].
>>
>> Perhaps we could consider a PIC reference without other arithmetic as
>> safe.  That would likely pick up the SYMBOL_REF_FUNCTION_P case you want
>> as well good deal many more PIC references as non-trapping.
>>
> Yes, I like this idea.
> 
> I tried to compile openssl with -m32 -fpic as an example, and counted
> how often the mem[pic+const] is hit: that was 2353 times, all kind of
> object refs.
> 
> Then I tried your idea, and only 54 unhandled pic refs remained, all of
> them looking like this:
> 
> (plus:SI (reg:SI 107)
>      (const:SI (plus:SI (unspec:SI [
>                      (symbol_ref:SI ("bf_init") [flags 0x2] <var_decl 
> 0x2ac00f7bac60 bf_init>)
>                  ] UNSPEC_GOTOFF)
>              (const_int 4164 [0x1044]))))
> 
> I believe that is a negligible fall out from such a big code base.
> 
> Although the pic references do no longer reach the
> SYMBOL_REF_FUNCTION_P in this version of the patch, I still see
> that happening without -fpic option, so I left it as is.
> 
> 
> Attached is the new version of my patch.
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
> 
> patch-pr79286.diff
> 
> 
> 2017-04-29  Bernd Edlinger  <bernd.edlinger@hotmail.de>
> 
>         rtl-optimizatoin/79286
>         * ira.c (update_equiv_regs): Revert to using may_tap_p again.
>         * rtlanal.c (rtx_addr_can_trap_p_1): SYMBOL_REF_FUNCTION_P can never
> 	trap.  PIC register plus a const unspec without offset can never trap.
OK.  Sorry for the delay.  I've been swamped.

jeff
diff mbox

Patch

2017-04-29  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        rtl-optimizatoin/79286
        * ira.c (update_equiv_regs): Revert to using may_tap_p again.
        * rtlanal.c (rtx_addr_can_trap_p_1): SYMBOL_REF_FUNCTION_P can never
	trap.  PIC register plus a const unspec without offset can never trap.

Index: gcc/ira.c
===================================================================
--- gcc/ira.c	(revision 247397)
+++ gcc/ira.c	(working copy)
@@ -3551,7 +3551,8 @@  update_equiv_regs (void)
 	  if (DF_REG_DEF_COUNT (regno) == 1
 	      && note
 	      && !rtx_varies_p (XEXP (note, 0), 0)
-	      && def_dominates_uses (regno))
+	      && (!may_trap_or_fault_p (XEXP (note, 0))
+		  || def_dominates_uses (regno)))
 	    {
 	      rtx note_value = XEXP (note, 0);
 	      remove_note (insn, note);
Index: gcc/rtlanal.c
===================================================================
--- gcc/rtlanal.c	(revision 247397)
+++ gcc/rtlanal.c	(working copy)
@@ -485,7 +485,7 @@  rtx_addr_can_trap_p_1 (const_rtx x, HOST_WIDE_INT
     case SYMBOL_REF:
       if (SYMBOL_REF_WEAK (x))
 	return 1;
-      if (!CONSTANT_POOL_ADDRESS_P (x))
+      if (!CONSTANT_POOL_ADDRESS_P (x) && !SYMBOL_REF_FUNCTION_P (x))
 	{
 	  tree decl;
 	  HOST_WIDE_INT decl_size;
@@ -644,8 +644,11 @@  rtx_addr_can_trap_p_1 (const_rtx x, HOST_WIDE_INT
 
     case PLUS:
       /* An address is assumed not to trap if:
-         - it is the pic register plus a constant.  */
-      if (XEXP (x, 0) == pic_offset_table_rtx && CONSTANT_P (XEXP (x, 1)))
+	 - it is the pic register plus a const unspec without offset.  */
+      if (XEXP (x, 0) == pic_offset_table_rtx
+	  && GET_CODE (XEXP (x, 1)) == CONST
+	  && GET_CODE (XEXP (XEXP (x, 1), 0)) == UNSPEC
+	  && offset == 0)
 	return 0;
 
       /* - or it is an address that can't trap plus a constant integer.  */