From patchwork Fri Oct 9 21:09:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 528426 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 E70E3140291 for ; Sat, 10 Oct 2015 08:11:55 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=uSjJw7XR; 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:from :subject:to:message-id:date:mime-version:content-type; q=dns; s= default; b=Bb6A6woasaKh6nDwICB/bEcUnFtJqP2fB2NbQqF4ZzNPm2FAfIElW me4+PJKzHwx2/xComK0zOWSEED+yHe2ncUOf7Gp+WGymqEDjJXqwYI13h83DQGJW 9HOHllCNclcnv9SUoMiMnKmCQCk6DXy3R/N3uNaaAirGCsEbIDRR2I= 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 :subject:to:message-id:date:mime-version:content-type; s= default; bh=yFm7v7hJhBH0R2bdWzCLINWSXIY=; b=uSjJw7XR/j11h8fRQL/E roMngyLNpMhj484PHejk7LYI78vybF1ybShLzkRi5KSGmKUaACdzkpV2+PMMdmcd XSWX+c72BV9ps0B8TCt/ZzotQQBIfSOpstpi30wFCiTyrhb8IImpYSYBer6HCYWk TGquBGwt/qSAEjPOZfvT0bY= Received: (qmail 63245 invoked by alias); 9 Oct 2015 21:11:10 -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 63179 invoked by uid 89); 9 Oct 2015 21:11:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 09 Oct 2015 21:11:04 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50181) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZkewP-0004pI-RP for gcc-patches@gnu.org; Fri, 09 Oct 2015 17:11:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkevy-0001bL-R0 for gcc-patches@gnu.org; Fri, 09 Oct 2015 17:11:01 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:49957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkevy-0001aT-8a for gcc-patches@gnu.org; Fri, 09 Oct 2015 17:10:34 -0400 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Zkevv-0000Zk-MR from Tom_deVries@mentor.com for gcc-patches@gnu.org; Fri, 09 Oct 2015 14:10:32 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Fri, 9 Oct 2015 22:10:30 +0100 From: Tom de Vries Subject: [PATCH] Fix parloops gimple_uid usage To: "gcc-patches@gnu.org" Message-ID: <56182D1D.2060106@mentor.com> Date: Fri, 9 Oct 2015 23:09:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 Hi, In tree-parloops.c:gather_scalar_reductions, we find the comment: ... /* As gimple_uid is used by the vectorizer in between vect_analyze_loop_form and destroy_loop_vec_info, we can set gimple_uid of reduc_phi stmts only now. */ reduction_list->traverse (NULL); ... However, the usage of gimple_uid seems to extend until the free_stmt_vec_info_vec call at the end of parallelize_loops (the pass top-level function). During free_stmt_vec_info_vec we test for gimple_uid == 0 in vinfo_for_stmt. By initializing all the phis in the function with -1 before using them in the reduct_phi stmts: ... destroy_loop_vec_info (simple_loop_info, true); destroy_loop_vec_info (simple_inner_loop_info, true); /* As gimple_uid is used by the vectorizer in between vect_analyze_loop_form and destroy_loop_vec_info, we can set gimple_uid of reduc_phi stmts only now. */ + basic_block bb; + FOR_EACH_BB_FN (bb, cfun) + for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi)) + gimple_set_uid (gsi_stmt (gsi), (unsigned int)-1); reduction_list->traverse (NULL); ... we trigger a sigsegv in vinfo_for_stmt while trying to access stmt_vec_info_vec[4294967295 - 1]. This patch fixes that by moving the calls to init_stmt_vec_info_vec and free_stmt_vec_info_vec from parallelize_loops and gather_scalar_reductions. Furthermore, now that the gimple_uids are properly initialized, we can in reduction_phi: - handle 0 (new phi) and -1 (initialized) values, both meaning the phi's not in the table, and - assert that returned entries in fact match the phi argument. OK for trunk if bootstrap and reg-test passes? Thanks, - Tom Fix parloops gimple_uid usage 2015-10-09 Tom de Vries * tree-parloops.c (reduction_phi): Handle cases that gimple_uid is 0 or -1. Add assert that returned entry matches phi argument. (parallelize_loops): Move calls to init_stmt_vec_info_vec and free_stmt_vec_info_vec ... (gather_scalar_reductions): ... here. Initialize gimple_uids of phis with -1. --- gcc/tree-parloops.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c index 741392b..7366318 100644 --- a/gcc/tree-parloops.c +++ b/gcc/tree-parloops.c @@ -237,9 +237,14 @@ reduction_phi (reduction_info_table_type *reduction_list, gimple *phi) if (reduction_list->elements () == 0 || phi == NULL) return NULL; + if (gimple_uid (phi) == (unsigned int)-1 + || gimple_uid (phi) == 0) + return NULL; + tmpred.reduc_phi = phi; tmpred.reduc_version = gimple_uid (phi); red = reduction_list->find (&tmpred); + gcc_assert (red == NULL || red->reduc_phi == phi); return red; } @@ -2392,6 +2397,9 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list loop_vec_info simple_inner_loop_info = NULL; bool allow_double_reduc = true; + if (!stmt_vec_info_vec.exists ()) + init_stmt_vec_info_vec (); + simple_loop_info = vect_analyze_loop_form (loop); if (simple_loop_info == NULL) return; @@ -2453,9 +2461,16 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list destroy_loop_vec_info (simple_loop_info, true); destroy_loop_vec_info (simple_inner_loop_info, true); + /* Release the claim on gimple_uid. */ + free_stmt_vec_info_vec (); + /* As gimple_uid is used by the vectorizer in between vect_analyze_loop_form - and destroy_loop_vec_info, we can set gimple_uid of reduc_phi stmts - only now. */ + and free_stmt_vec_info_vec, we can set gimple_uid of reduc_phi stmts only + now. */ + basic_block bb; + FOR_EACH_BB_FN (bb, cfun) + for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi)) + gimple_set_uid (gsi_stmt (gsi), (unsigned int)-1); reduction_list->traverse (NULL); } @@ -2603,7 +2618,6 @@ parallelize_loops (void) gcc_obstack_init (&parloop_obstack); reduction_info_table_type reduction_list (10); - init_stmt_vec_info_vec (); FOR_EACH_LOOP (loop, 0) { @@ -2695,7 +2709,6 @@ parallelize_loops (void) n_threads, &niter_desc); } - free_stmt_vec_info_vec (); obstack_free (&parloop_obstack, NULL); /* Parallelization will cause new function calls to be inserted through -- 1.9.1