From patchwork Wed Jun 28 13:36:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 106533 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1024555qge; Wed, 28 Jun 2017 06:36:50 -0700 (PDT) X-Received: by 10.84.210.106 with SMTP id z97mr12054733plh.6.1498657010051; Wed, 28 Jun 2017 06:36:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498657010; cv=none; d=google.com; s=arc-20160816; b=nQtiojPC3EGECGsfsup0eo5RirCT/LxgR6c8affKQiEfdf81BNT7eb3I3GxeVZZsVm VeiV0T0NizNocIR4aXVx4UQ15tAXSipmLoDPebq7nMJ1ndIT4KjMBojseqokW5Uofhhn N9DOpnFD52HV1Qz4HOttiN10+zFG1MI8onJEyScE0yFJ6ga8Uu8Txp4opft9h/4U2Vvd fe1FO0ZaVU/blXMwK3x98wChcQ1AOvNORbalZ0ecpwQ5IsL0udr5j+mc4qTWX0BNiTzV TryXHo7qTAt29TUVdnGueHxJhZIkGqGLmRqq1OHZUyTZdsqkfvhD5Ytkkj7u0OINNiRQ /8Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:message-id:date:subject:mail-followup-to:to :from:delivered-to:sender:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:mailing-list:dkim-signature :domainkey-signature:arc-authentication-results; bh=MM8pnR7EoqwxCgfdGvLC/lahQALv1k21OqvOjpR9pu8=; b=WzapyDJ33eVj2DC8MTOP6k/3BVo6oL8v9Xj1Geeq4BcJ3/SuPE0aGCqi5E1c/CVAjZ WPqCyFnqhnMlrabW09qKEfTB8iNnkLqMr8EVS+MVyC0/D3c2Yv1viGgFNlJa0wU7jt4r umUAN5tSLeO0Q64XPKsbayG9X3QG+R0TfO+heCHd/fk/aNtFMvjvP6Ak6epRiL9IPSm9 Uj5Bt/SwTbM9L7A26vZtolzq48qdD6KEBdVpIbSEyiCNCo0WMqEbC5u4TsyW5bKwZCvr 2PivMx6o10yGbJcg0uJcVp+5I3xCb1RKwUAGBMTsUaUYVfS420YRRXQ8HStOR+TBCnpy T2sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.b=jBFTrnB6; spf=pass (google.com: domain of gcc-patches-return-457068-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-457068-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id k24si1561733pfg.84.2017.06.28.06.36.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 06:36:50 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-457068-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.b=jBFTrnB6; spf=pass (google.com: domain of gcc-patches-return-457068-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-457068-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type; q=dns; s= default; b=ZUA0+mN2yQRSwHBcHg8kxN9Ljc0UNXZaVoiKFB1122r7JUJeaI6R2 rmrUcahI3WyEtANhriO4f6EugL+1HQpphtZiEImRuBfF/pvekaQPb4qbaPt1lk8L tHzyQgHlFxgxRj2/pNJaS4aJt+ZciX+68A5snOwSsrZqtICJnw9V8k= 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:from :to:subject:date:message-id:mime-version:content-type; s= default; bh=BXql3W7J85jm09KEHd7/WM+LIyo=; b=jBFTrnB6/D2rYUnUhjc2 j/IbQ9UC9eS8hDyD3CeFqXJqlAkrjdu/WlktWAKAqHMJfWaUDKhLTQaWxG0x2iJ4 MJ5MKRzIdmRsHQ7kdQtjEjU2W3VP9ovWVVRD88KL7HdxWgz2lnuUstNNtmK0yj0v JSuO4vkiG2p7Hi4Gw3dzrdg= Received: (qmail 28001 invoked by alias); 28 Jun 2017 13:36:27 -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 27983 invoked by uid 89); 28 Jun 2017 13:36:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f52.google.com Received: from mail-wm0-f52.google.com (HELO mail-wm0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Jun 2017 13:36:24 +0000 Received: by mail-wm0-f52.google.com with SMTP id i127so59204216wma.0 for ; Wed, 28 Jun 2017 06:36:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:subject:date:message-id :user-agent:mime-version; bh=MM8pnR7EoqwxCgfdGvLC/lahQALv1k21OqvOjpR9pu8=; b=UjTzmMnBO7kcjWUty9DAYlbuJQJAnhWBlv2S9f8uUMHaVv1yRNqisDX7iQDayDAArd ELMRVgdvm3HGgS0MoG9Q+EkDEsKVnK7OKdbw6AnvVFmz626aA0TR5xYmAzkykpVr6Kzv pF3ty8n5QfRKVdpWi9c2x+21b2bs9WqZ0cF6qvt4P01B/RxT2pCNhw7PK4AU1AQIi/Fg omEDAvgCues/yVcKH3KK/E5SxDfp5ee4bSuE238Ju8HDzWvxhjxpPAd1AZYIQXkF+dOH b3XPVvk3P+YRSVEmR22SIo6ToHD4u1H1vfGZhJ55eRxl8AHSDvAAJkFyaHaK1ox2Qpes uL0A== X-Gm-Message-State: AKS2vOzVBjxkenJFbSGiS2iDS3D2My5btmfgF08sLFy7bIFr7faKT6jw qPbi5lZPw+RNoQS+1LGpxw== X-Received: by 10.28.109.18 with SMTP id i18mr7263291wmc.97.1498656981988; Wed, 28 Jun 2017 06:36:21 -0700 (PDT) Received: from localhost (92.40.249.75.threembb.co.uk. [92.40.249.75]) by smtp.gmail.com with ESMTPSA id x5sm1515545wrd.50.2017.06.28.06.36.20 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 28 Jun 2017 06:36:20 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Tweak BB analysis for dr_analyze_innermost Date: Wed, 28 Jun 2017 14:36:18 +0100 Message-ID: <87r2y46xpp.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 dr_analyze_innermost had a "struct loop *nest" parameter that acted like a boolean. This was added in r179161, with the idea that a null nest selected BB-level analysis rather than loop analysis. The handling seemed strange though. If the DR was part of a loop, we still tried to express the base and offset values as IVs, potentially giving a nonzero step. If that failed for any reason, we'd revert to using the original base and offset, just as we would if we hadn't asked for an IV in the first place. It seems more natural to use the !in_loop handling whenever nest is null and always set the step to zero. This actually enables one more SLP opportunity in bb-slp-pr65935.c. I checked out r179161 and tried the patch there. The test case added in that revision still passes, so I don't think there was any particular need to check simple_iv. Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? Richard 2017-06-28 Richard Sandiford gcc/ * tree-data-ref.c (dr_analyze_innermost): Replace the "nest" parameter with a "loop" parameter and use it instead of the loop containing DR_STMT. Don't check simple_iv when doing BB analysis. Describe the two analysis modes in the comment. gcc/testsuite/ * gcc.dg/vect/bb-slp-pr65935.c: Expect SLP to be used in main as well. Index: gcc/tree-data-ref.c =================================================================== --- gcc/tree-data-ref.c 2017-06-28 14:33:41.294720044 +0100 +++ gcc/tree-data-ref.c 2017-06-28 14:35:30.475155670 +0100 @@ -749,15 +749,29 @@ canonicalize_base_object_address (tree a return build_fold_addr_expr (TREE_OPERAND (addr, 0)); } -/* Analyzes the behavior of the memory reference DR in the innermost loop or - basic block that contains it. Returns true if analysis succeed or false - otherwise. */ +/* Analyze the behavior of memory reference DR. There are two modes: + + - BB analysis. In this case we simply split the address into base, + init and offset components, without reference to any containing loop. + The resulting base and offset are general expressions and they can + vary arbitrarily from one iteration of the containing loop to the next. + The step is always zero. + + - loop analysis. In this case we analyze the reference both wrt LOOP + and on the basis that the reference occurs (is "used") in LOOP; + see the comment above analyze_scalar_evolution_in_loop for more + information about this distinction. The base, init, offset and + step fields are all invariant in LOOP. + + Perform BB analysis if LOOP is null, or if LOOP is the function's + dummy outermost loop. In other cases perform loop analysis. + + Return true if the analysis succeeded and store the results in DR if so. + BB analysis can only fail for bitfield or reversed-storage accesses. */ bool -dr_analyze_innermost (struct data_reference *dr, struct loop *nest) +dr_analyze_innermost (struct data_reference *dr, struct loop *loop) { - gimple *stmt = DR_STMT (dr); - struct loop *loop = loop_containing_stmt (stmt); tree ref = DR_REF (dr); HOST_WIDE_INT pbitsize, pbitpos; tree base, poffset; @@ -806,22 +820,11 @@ dr_analyze_innermost (struct data_refere if (in_loop) { - if (!simple_iv (loop, loop_containing_stmt (stmt), base, &base_iv, - nest ? true : false)) + if (!simple_iv (loop, loop, base, &base_iv, true)) { - if (nest) - { - if (dump_file && (dump_flags & TDF_DETAILS)) - fprintf (dump_file, "failed: evolution of base is not" - " affine.\n"); - return false; - } - else - { - base_iv.base = base; - base_iv.step = ssize_int (0); - base_iv.no_overflow = true; - } + if (dump_file && (dump_flags & TDF_DETAILS)) + fprintf (dump_file, "failed: evolution of base is not affine.\n"); + return false; } } else @@ -843,22 +846,11 @@ dr_analyze_innermost (struct data_refere offset_iv.base = poffset; offset_iv.step = ssize_int (0); } - else if (!simple_iv (loop, loop_containing_stmt (stmt), - poffset, &offset_iv, - nest ? true : false)) + else if (!simple_iv (loop, loop, poffset, &offset_iv, true)) { - if (nest) - { - if (dump_file && (dump_flags & TDF_DETAILS)) - fprintf (dump_file, "failed: evolution of offset is not" - " affine.\n"); - return false; - } - else - { - offset_iv.base = poffset; - offset_iv.step = ssize_int (0); - } + if (dump_file && (dump_flags & TDF_DETAILS)) + fprintf (dump_file, "failed: evolution of offset is not affine.\n"); + return false; } } @@ -1077,7 +1069,7 @@ create_data_ref (loop_p nest, loop_p loo DR_REF (dr) = memref; DR_IS_READ (dr) = is_read; - dr_analyze_innermost (dr, nest); + dr_analyze_innermost (dr, nest != NULL ? loop : NULL); dr_analyze_indices (dr, nest, loop); dr_analyze_alias (dr); Index: gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c =================================================================== --- gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c 2017-06-28 14:33:41.294720044 +0100 +++ gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c 2017-06-28 14:34:09.357523025 +0100 @@ -57,4 +57,6 @@ int main() return 0; } -/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" } } */ +/* We should also be able to use 2-lane SLP to initialize the real and + imaginary components in the first loop of main. */ +/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp1" } } */