From patchwork Tue Jun 9 13:26:51 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 482233 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 8ABCC1404A8 for ; Tue, 9 Jun 2015 23:27:03 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=NW2+4cAH; 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 :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=dmDATrk0EHJpFeTrVg HglMeyektGSn9wONJOKE4fgev40pj/jZrTamHLNwSrVK1Tt56NQVDrQBcCt4iccT hH5TJhz6MTicoZp9G6FBgdZw5JoXC04sfL/h9rcsMIHo2PIqDKBby77gavHM27/p DmL0Tzk1/WU9i0R3GSTfQuRE8= 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 :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=26RBgNEunmPXKdOGjtr7vG+t ipk=; b=NW2+4cAHO4tQZEy5Z8w5j5HIFmD66b4NB8quafJbSeU1Y7oDo7siLEo8 6jt0k2Em4ynS26yJgmjfvqd1nsYDAr5sywhBUrup/dPGU+zYfFVTnIMOC9cIpYMC iMWpeTh7xTYlAQU+bx3n6Hz9gqQxcqDKV7mX4MsnUEenTkWzHwM= Received: (qmail 5774 invoked by alias); 9 Jun 2015 13:26: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 5764 invoked by uid 89); 9 Jun 2015 13:26:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 09 Jun 2015 13:26:53 +0000 Received: by obbir4 with SMTP id ir4so12719419obb.1 for ; Tue, 09 Jun 2015 06:26:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.71.20 with SMTP id u20mr14958481oia.81.1433856411378; Tue, 09 Jun 2015 06:26:51 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Tue, 9 Jun 2015 06:26:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jun 2015 15:26:51 +0200 Message-ID: Subject: Re: [PATCH] Yet another simple fix to enhance outer-loop vectorization. From: Richard Biener To: Yuri Rumyantsev Cc: gcc-patches , Igor Zamyatin X-IsSubscribed: yes On Mon, Jun 8, 2015 at 12:27 PM, Yuri Rumyantsev wrote: > Hi All, > > Here is a simple fix which allows duplication of outer loops to > perform peeling for number of iterations if outer loop is marked with > pragma omp simd. > > Bootstrap and regression testing did not show any new failures. > Is it OK for trunk? Hmm, I don't remember needing to adjust rename_variables_in_bb when teaching loop distibution to call slpeel_tree_duplicate_to_edge_cfg on non-innermost loops... (I just copied, I never called slpeel_can_duplicate_loop_p though). So - you should just remove the loop->inner condition from slpeel_can_duplicate_loop_p as it is used by non-vectorizer code as well (yeah, I never merged the nested loop support for loop distribution...). alignment in vect_enhance_data_refs_alignment? Thus add || ->inner to /* Check if we can possibly peel the loop. */ if (!vect_can_advance_ivs_p (loop_vinfo) || !slpeel_can_duplicate_loop_p (loop, single_exit (loop))) do_peeling = false; ? I also can't see why the improvement has to be gated on force_vect, it surely looks profitable to enable more outer loop vectorization in general, no? How do the cost model calculations end up with peeling the outer loop for niter? On targets which don't support unaligned accesses we're left with versioning for alignment. Isn't peeling for alignment better there? Thus only disallow peeling for alignment if there is no unhandled alignment? Thanks, Richard. > ChangeLog: > > 2015-06-08 Yuri Rumyantsev > > * tree-vect-loop-manip.c (rename_variables_in_bb): Add argument > to allow renaming of PHI arguments on edges incoming from outer > loop header, add corresponding check before start PHI iterator. > (slpeel_tree_duplicate_loop_to_edge_cfg): Introduce new bool > variable DUPLICATE_OUTER_LOOP and set it to true for outer loops > with true force_vectorize. Set-up dominator for outer loop too. > Pass DUPLICATE_OUTER_LOOP as argument to rename_variables_in_bb. > (slpeel_can_duplicate_loop_p): Allow duplicate of outer loop if it > was marked with force_vectorize and has restricted cfg. > * tre-vect-loop.c (vect_analyze_loop_2): Prohibit alignment peeling > for outer loops. > > gcc/testsuite/ChangeLog: > * gcc.dg/vect/vect-outer-simd-2.c: New test. Index: tree-vect-loop.c =================================================================== --- tree-vect-loop.c (revision 224100) +++ tree-vect-loop.c (working copy) @@ -1879,6 +1879,10 @@ return false; } + /* Peeling for alignment is not supported for outer-loop vectorization. */ + if (LOOP_VINFO_LOOP (loop_vinfo)->inner) + LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) = 0; I think you can't simply do this - if vect_enhance_data_refs_alignment decided to peel for alignment then it has adjusted the DRs alignment info already. So instead of the above simply disallow peeling for