From patchwork Fri Apr 17 08:34:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Enkovich X-Patchwork-Id: 461979 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 6293E1402D5 for ; Fri, 17 Apr 2015 18:37:03 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass reason="1024-bit key; unprotected key" header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=W+9+54/N; dkim-adsp=none (unprotected policy); dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=g1c9n3DXkXiwAEnBS Ojn/U367kpqFNIMQ6cRqkLBkZG2QF1Y3jYedFkw9J3BwOM3s+iRYaOK04XZ5DrZK Ncxz9/6QAxJ9DagD5pSPkhETgySQ79P28QQzSkV9Ef4firCHWGJHwOgYQVNcCCQr 0GqB5yHIcu2c2buiLQUn6Pb64Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=NSc3IpWt0plAbN70B84NHQr vcZ0=; b=W+9+54/N2ZuKls9qC2FdPOa5u4lY8NckwdBrZmDVNcnkPju8OIaec0v LSL/nT6z4SZ0MNyv34Brppu8Vt+QxYh1xC4BB9Hz5EM4OiNViTOmMuo9WVHkAxb0 3/VPpyKLroyHagtw4YPOSMUsfHJCzIkQPaDT3sqxS47p0hV1Gpks= Received: (qmail 119397 invoked by alias); 17 Apr 2015 08:36:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 119381 invoked by uid 89); 17 Apr 2015 08:36:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f174.google.com Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 17 Apr 2015 08:36:51 +0000 Received: by widdi4 with SMTP id di4so12427928wid.0 for ; Fri, 17 Apr 2015 01:36:48 -0700 (PDT) X-Received: by 10.194.109.9 with SMTP id ho9mr3429279wjb.29.1429259808799; Fri, 17 Apr 2015 01:36:48 -0700 (PDT) Received: from msticlxl57.ims.intel.com ([192.55.54.42]) by mx.google.com with ESMTPSA id z13sm13641855wjr.44.2015.04.17.01.36.45 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Apr 2015 01:36:47 -0700 (PDT) Date: Fri, 17 Apr 2015 11:34:45 +0300 From: Ilya Enkovich To: Jeff Law Cc: gcc-patches , rdsandiford@googlemail.com Subject: Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386 Message-ID: <20150417083445.GA6178@msticlxl57.ims.intel.com> References: <20150310150027.GC27860@msticlxl57.ims.intel.com> <8761a22ecm.fsf@googlemail.com> <552CA415.5060206@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On 15 Apr 14:07, Ilya Enkovich wrote: > 2015-04-14 8:22 GMT+03:00 Jeff Law : > > On 03/15/2015 02:30 PM, Richard Sandiford wrote: > >> > >> Ilya Enkovich writes: > >>> > >>> This patch allows propagation of loop invariants for i386 if propagated > >>> value is a constant to be used in address operand. Bootstrapped and > >>> tested on x86_64-unknown-linux-gnu. OK for trunk or stage 1? > >> > >> > >> Is it necessary for this to be a target hook? The concept doesn't seem > >> particularly target-specific. We should only propagate into the address > >> if the new cost is no greater than the old cost, but if the address > >> meets that condition and if propagating at this point in the pipeline is > >> a win on x86, then wouldn't it be a win for other targets too? > > > > I agree with Richard here. I can't see a strong reason why this should be a > > target hook. > > > > Perhaps part of the issue here is the address costing metrics may not have > > enough context to make good decisions. In which case what context do they > > need? > > At this point I don't insist on a target hook. The main reasoning was > to not affect other targets. If we extend propagation for non constant > values different aspects may appear. E.g. possible register pressure > changes may significantly affect ia32. I just wanted to have an > instrument to play with a propagation on x86 not affecting other > targets. I don't have an opportunity to test possible performance > implications on non-x86 targets. Don't expect (significant) > regressions there but who knows... > > I'll remove the hook from this patch. Will probably introduce it later > if some target specific cases are found. > > Thanks, > Ilya > > > > > Jeff Here is a version with no hook. Bootstrapped and tested on x86_64-unknown-linux-gnu. Is it OK for trunk? Thanks, Ilya --- gcc/ 2015-04-17 Ilya Enkovich PR target/65103 * fwprop.c (forward_propagate_into): Propagate loop invariants if a target says so. gcc/testsuite/ 2015-04-17 Ilya Enkovich PR target/65103 * gcc.target/i386/pr65103-2.c: New. diff --git a/gcc/fwprop.c b/gcc/fwprop.c index fc64ec9..82ebd01 100644 --- a/gcc/fwprop.c +++ b/gcc/fwprop.c @@ -1365,8 +1365,18 @@ forward_propagate_into (df_ref use) if (DF_REF_IS_ARTIFICIAL (def)) return false; - /* Do not propagate loop invariant definitions inside the loop. */ - if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father) + def_insn = DF_REF_INSN (def); + if (multiple_sets (def_insn)) + return false; + def_set = single_set (def_insn); + if (!def_set) + return false; + + /* Do not propagate loop invariant definitions inside the loop. + Allow address constant propagation. */ + if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father + && (DF_REF_TYPE (use) == DF_REF_REG_USE + || GET_CODE (SET_SRC (def_set)) != CONST)) return false; /* Check if the use is still present in the insn! */ @@ -1379,13 +1389,6 @@ forward_propagate_into (df_ref use) if (!reg_mentioned_p (DF_REF_REG (use), parent)) return false; - def_insn = DF_REF_INSN (def); - if (multiple_sets (def_insn)) - return false; - def_set = single_set (def_insn); - if (!def_set) - return false; - /* Only try one kind of propagation. If two are possible, we'll do it on the following iterations. */ if (forward_propagate_and_simplify (use, def_insn, def_set) diff --git a/gcc/testsuite/gcc.target/i386/pr65103-2.c b/gcc/testsuite/gcc.target/i386/pr65103-2.c new file mode 100644 index 0000000..b7a32f7 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr65103-2.c @@ -0,0 +1,24 @@ +/* { dg-do compile { target ia32 } } */ +/* { dg-require-effective-target pie } */ +/* { dg-options "-O2 -fPIE" } */ +/* { dg-final { scan-assembler-not "GOTOFF," } } */ + +typedef struct S +{ + int a; + int b; +} S; +struct S gs; + +extern int compute ( struct S * ); + +int test( void ) +{ + int t = -1; + while (t) + { + gs.a++; + t = compute (&gs); + } + return 0; +}