From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by sourceware.org (Postfix) with ESMTPS id DD0E338387E1 for ; Mon, 13 Jun 2022 11:38:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DD0E338387E1 Received: by mail-qv1-xf2d.google.com with SMTP id i19so4095212qvu.13 for ; Mon, 13 Jun 2022 04:38:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mRCNIyk2M+nIyE5wnZBNJ3RYr3+CMt9xvGktOcgS2/c=; b=7iPKVhY5s9PYruY0Vj0soOvOvNW6hiYZ4NvEnet6qiXcuSy7v4PPYX1JdqZN6sF08C B8XOI+JG5kGp854NsXQMC4nWkDsooAU3wIbWIP1ql8UEcNQ1VqNdL27dRHAzzUbQLhqV KG+Kk8d/oS/15yKtAfjGZxiFysREDRozQbcxmpk1ivgL33ri7lSEyPfKXjTQh6lrWjnO o16VjTf614FU30mXAVVz4Xt1uqgv3qaXfaIBgqQf6SGV8lNOLCJHd73rO3E7TZn5dfXA Egk24qhsvMSgAPgNYeKf389cUUk885g16v57BtZZvKQPaNLBGAD8V6xSh8SsfpF8Iimc nSaQ== X-Gm-Message-State: AOAM532buYwjmpUTuQ4HyYfd2WIPlfeMBbTWxZP7eHhB6iTSnN8AwWHX 3DNw/n+QNTvzqyf2tldNlYR8PG+1c4z0OQBbNPY= X-Google-Smtp-Source: ABdhPJwSwoMw/rRtl7su9HBWbjV3Y1evSDBxT+E1otI9pzIyqDqNP51XtcekQfBhuG4rCHMy8d61noSzvuh/+d66y/w= X-Received: by 2002:a05:6214:d8d:b0:464:51cc:a552 with SMTP id e13-20020a0562140d8d00b0046451cca552mr43716550qve.122.1655120309185; Mon, 13 Jun 2022 04:38:29 -0700 (PDT) MIME-Version: 1.0 References: <948236dc-f881-f24f-bee5-7a804b1793ec@linux.ibm.com> In-Reply-To: <948236dc-f881-f24f-bee5-7a804b1793ec@linux.ibm.com> From: Richard Biener Date: Mon, 13 Jun 2022 13:38:18 +0200 Message-ID: Subject: Re: [PATCH] vect: Move suggested_unroll_factor applying [PR105940] To: "Kewen.Lin" Cc: GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2022 11:38:31 -0000 On Mon, Jun 13, 2022 at 12:02 PM Kewen.Lin wrote: > > Hi, > > As PR105940 shown, when rs6000 port tries to assign > m_suggested_unroll_factor by 4 or so, there will be ICE > on below statement: > > exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo), > loop_vinfo->suggested_unroll_factor); > > In function vect_analyze_loop_2, the current place of > suggested_unroll_factor applying can't guarantee it's > applied for all cases. As the case shows, vectorizer > could retry with SLP forced off, the vf is reset by > saved_vectorization_factor which isn't applied with > suggested_unroll_factor before. It means it can end > up with one vf which neglects suggested_unroll_factor. > I think it's off design, we should move the applying > of suggested_unroll_factor after start_over. > > Bootstrapped and regtested on x86_64-redhat-linux, > aarch64-linux-gnu and powerpc64{,le}-linux-gnu. > > Is it ok for trunk? OK (I think the GCC 12 branch is also affected). Richard. > > BR, > Kewen > ----- > PR tree-optimization/105940 > > gcc/ChangeLog: > > * tree-vect-loop.cc (vect_analyze_loop_2): Move the place of > applying suggested_unroll_factor after start_over. > --- > gcc/tree-vect-loop.cc | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc > index 896218f23ea..af955d26f8d 100644 > --- a/gcc/tree-vect-loop.cc > +++ b/gcc/tree-vect-loop.cc > @@ -2393,15 +2393,15 @@ vect_analyze_loop_2 (loop_vec_info loop_vinfo, bool &fatal, > set of rgroups. */ > gcc_assert (LOOP_VINFO_MASKS (loop_vinfo).is_empty ()); > > + /* This is the point where we can re-start analysis with SLP forced off. */ > +start_over: > + > /* Apply the suggested unrolling factor, this was determined by the backend > during finish_cost the first time we ran the analyzis for this > vector mode. */ > if (loop_vinfo->suggested_unroll_factor > 1) > LOOP_VINFO_VECT_FACTOR (loop_vinfo) *= loop_vinfo->suggested_unroll_factor; > > - /* This is the point where we can re-start analysis with SLP forced off. */ > -start_over: > - > /* Now the vectorization factor is final. */ > poly_uint64 vectorization_factor = LOOP_VINFO_VECT_FACTOR (loop_vinfo); > gcc_assert (known_ne (vectorization_factor, 0U)); > -- > 2.27.0