From patchwork Tue Feb 22 16:48:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 51308 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0F0A03945C39 for ; Tue, 22 Feb 2022 16:48:49 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 730E33857818 for ; Tue, 22 Feb 2022 16:48:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 730E33857818 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: kL2H9es0kTtUWH3NZe7qyPOjM/sesXOeubVSpHE9GWIEhLp3ytLITrbnJIKngTQLsCZpfZNPEL 9s4kGUPrI2JI7TupqRehh9ciqwT1gj304+zVe+p9lkM7Jj+aJuqNXxr7q7hAvIvUd5x/rthUbK SUZBot80xIQjNvVuy1fARxA0dV4GYDBCgJmkfMuQhtybYnTtK62vvcHHXg+8GFnnrLe2SRzEdd NfoFMasKo+uSlNOnREKFu6LX8GRp7McQoouB1JNoHvikGSd+PQDq6ZgPnK0q3PLz+WTR+E2UZ6 4+XDFM6NVJVwjzyKZKdbPCRF X-IronPort-AV: E=Sophos;i="5.88,387,1635235200"; d="scan'208,223";a="72265666" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 22 Feb 2022 08:48:30 -0800 IronPort-SDR: C2vly/ENSr/aJRCsIeExeowtYuaGB+2TzwGn7o/SQuriM/jNQpBRq17yeTMQpwKKRnqUCAKdlh d/ggUUOVS/bH6fvi8nuateOXvVXL0DYbyvELu3z43w/b8DzskuKN0phxwxFswiXAnZkDt9YxDV khKskXIuCit1Xrs2Xj+ZGN3MuiMaNDfBOdocOuS88hIHu1pmnvQe1WQjuLoUg4rRTQ9bANpvUz 6zdwdBsn0N1p80uLrhr7Af/2NBFGDbg4BsLXBW8K9ftut4wrvAVm2/TTK59X3DfD0exYPMw2N7 8dc= From: Thomas Schwinge To: Julian Brown , Subject: Further simplify 'gcc/omp-oacc-neuter-broadcast.cc:record_field_map_t' (was: [PATCH 1/4] openacc: Middle-end worker-partitioning support) In-Reply-To: <87tujp7k66.fsf@euler.schwinge.homeip.net> References: <2ef7b2ebaf056858d6484a260c3897f844e2df4a.1614685766.git.julian@codesourcery.com> <87pmuts685.fsf@euler.schwinge.homeip.net> <20210806094958.149035b6@squid.athome> <87tujp7k66.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 22 Feb 2022 17:48:13 +0100 Message-ID: <87wnhmonjm.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , Cc: Jakub Jelinek , Tobias Burnus Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! On 2021-08-16T12:34:09+0200, I wrote: > On 2021-08-06T09:49:58+0100, Julian Brown wrote: >> On Wed, 4 Aug 2021 15:13:30 +0200 >> Thomas Schwinge wrote: >> >>> 'oacc_do_neutering' is the 'execute' function of the pass, so that >>> means every time this executes, a fresh 'field_map' is set up, no >>> state persists across runs (assuming I'm understanding that >>> correctly). Why don't we simply use standard (non-GC) memory >>> management for that? "For convenience" shall be fine as an answer >>> ;-) -- but maybe instead of figuring out the right GC annotations, >>> changing the memory management will be easier? (Or, of course, maybe >>> I completely misunderstood that?) >> >> I suspect you're right, and there's no need for this to be GC-allocated >> memory. If non-standard memory allocation will work out fine, we should > > ("non-GC", I suppose.) > >> probably use that instead. > > Pushed "Avoid 'GTY' use for 'gcc/omp-oacc-neuter-broadcast.cc:field_map'" > to master branch in commit 049eda8274b7394523238b17ab12c3e2889f253e In commit 0fe9176f410accc767e0abab010aec843b2e7ea6 I've now pushed "Further simplify 'gcc/omp-oacc-neuter-broadcast.cc:record_field_map_t'" to master branch, see attached. Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 From 0fe9176f410accc767e0abab010aec843b2e7ea6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 13 Aug 2021 21:17:55 +0200 Subject: [PATCH] Further simplify 'gcc/omp-oacc-neuter-broadcast.cc:record_field_map_t' Now that I've resolved GCC 'hash_map' issues (a while ago already), we may further simplify this after commit 049eda8274b7394523238b17ab12c3e2889f253e "Avoid 'GTY' use for 'gcc/omp-oacc-neuter-broadcast.cc:field_map'": as 'hash_map' Value, directly store 'field_map_t' objects, not pointers to manually allocated 'field_map_t' objects. gcc/ * omp-oacc-neuter-broadcast.cc (record_field_map_t): Further simplify. Adjust all users. --- gcc/omp-oacc-neuter-broadcast.cc | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/gcc/omp-oacc-neuter-broadcast.cc b/gcc/omp-oacc-neuter-broadcast.cc index 7fb691d7155..314161e38f5 100644 --- a/gcc/omp-oacc-neuter-broadcast.cc +++ b/gcc/omp-oacc-neuter-broadcast.cc @@ -538,7 +538,7 @@ typedef hash_map field_map_t; to propagate, to the field in the record type that should be used for transmission and reception. */ -typedef hash_map record_field_map_t; +typedef hash_map record_field_map_t; static void install_var_field (tree var, tree record_type, field_map_t *fields) @@ -1168,8 +1168,7 @@ worker_single_copy (basic_block from, basic_block to, gcc_assert (TREE_CODE (var) == VAR_DECL); /* If we had no record type, we will have no fields map. */ - field_map_t **fields_p = record_field_map->get (record_type); - field_map_t *fields = fields_p ? *fields_p : NULL; + field_map_t *fields = record_field_map->get (record_type); if (worker_partitioned_uses->contains (var) && fields @@ -1684,10 +1683,9 @@ oacc_do_neutering (unsigned HOST_WIDE_INT bounds_lo, field_vec.qsort (sort_by_size_then_ssa_version_or_uid); - field_map_t *fields = new field_map_t; - bool existed; - existed = record_field_map.put (record_type, fields); + field_map_t *fields + = &record_field_map.get_or_insert (record_type, &existed); gcc_checking_assert (!existed); /* Insert var fields in reverse order, so the last inserted element @@ -1818,8 +1816,6 @@ oacc_do_neutering (unsigned HOST_WIDE_INT bounds_lo, &partitioned_var_uses, &record_field_map, &blk_offset_map, writes_gang_private); - for (auto it : record_field_map) - delete it.second; record_field_map.empty (); /* These are supposed to have been 'delete'd by 'neuter_worker_single'. */ -- 2.34.1