From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24851 invoked by alias); 23 Jun 2017 04:35:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 24773 invoked by uid 89); 23 Jun 2017 04:35:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=story X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jun 2017 04:35:36 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2B4D97D0C2; Fri, 23 Jun 2017 04:35:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2B4D97D0C2 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@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2B4D97D0C2 Received: from localhost.localdomain (ovpn-117-117.phx2.redhat.com [10.3.117.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8F2065C469; Fri, 23 Jun 2017 04:35:33 +0000 (UTC) Subject: Re: [PATCH][ PR rtl-optimization/79286] Drop may_trap_p exception to testing dominance in update_equiv_regs To: Bernd Edlinger , "gcc-patches@gcc.gnu.org" References: <464887c0-7474-b0c2-6c99-e539859c1642@redhat.com> <713d5000-97b7-4933-3e4f-22d6de1331d3@redhat.com> From: Jeff Law Message-ID: <7646ae03-937a-2ead-9845-128c51547773@redhat.com> Date: Fri, 23 Jun 2017 04:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01728.txt.bz2 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] 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 > > 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