This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ PR rtl-optimization/79286] Drop may_trap_p exception to testing dominance in update_equiv_regs
- From: Jeff Law <law at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 22 Jun 2017 22:35:33 -0600
- Subject: Re: [PATCH][ PR rtl-optimization/79286] Drop may_trap_p exception to testing dominance in update_equiv_regs
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2B4D97D0C2
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2B4D97D0C2
- References: <AM4PR0701MB216261D19300246ACE8F85BEE41C0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <464887c0-7474-b0c2-6c99-e539859c1642@redhat.com> <AM4PR0701MB2162813D9C53F9CE4A39D624E4130@AM4PR0701MB2162.eurprd07.prod.outlook.com> <713d5000-97b7-4933-3e4f-22d6de1331d3@redhat.com> <AM4PR0701MB216212D47DFF1723ED41F7E6E4120@AM4PR0701MB2162.eurprd07.prod.outlook.com>
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