From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id ADE0139450CE for ; Mon, 16 Aug 2021 13:33:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADE0139450CE Received: by mail-ej1-x632.google.com with SMTP id lo4so31693548ejb.7 for ; Mon, 16 Aug 2021 06:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9wnvKIf4RhF/hpX4AHQSD/DxfGf8aEpKZiFvJCVUluo=; b=pYTUgHZdb7I5v0v3/czCKOz5tux0eMSHxSHbOk9+5Bi1Bw4E1VlAZ2eOSJux09ZqVg 2urhuwnf/RgMQphh03H3dcOjza1vBpsrX8DcHCcqJ057y9Su8gLMC1rnjxbKkIPPnVlF RrCqT7xOnTY4j1N3Pl3gypbJmWz3O1JeXh4bcvn4Puru3Rl2IVT5TRBrpO6lTU94DVdL EfdZ/MU+N3FL5EexE0E6dVx8CnYkSXzURWXAlddG0GrUgqjYL7s/3RsC/VHw9wVkc9WE 5QEISo4zBY4y7vF8jTOqZwduAXfDhlY1i0XD8ceV/bxiCQQgvxTz9q4q6PZb1YklQuz0 4aWg== X-Gm-Message-State: AOAM530XuKvlOh+iJd9kLKKHH1bPxLh2FAysuduZ0t3bc3Qo20ZhdJhj HhYRUJ5hy8vvwKCleInIAR0rzJD+wq3z6bNsefo= X-Google-Smtp-Source: ABdhPJztzMl69Q1XByhZ56paa4Coy2daVFTQygd/r++f2pecNW4fpzmnYdW7o+HxbSmY2PMtb6FnTi2K2O1hNtE8dpQ= X-Received: by 2002:a17:906:6815:: with SMTP id k21mr16182132ejr.371.1629120836592; Mon, 16 Aug 2021 06:33:56 -0700 (PDT) MIME-Version: 1.0 References: <87r1f6qzmx.fsf@euler.schwinge.homeip.net> <87eeat7e52.fsf@euler.schwinge.homeip.net> In-Reply-To: <87eeat7e52.fsf@euler.schwinge.homeip.net> From: Richard Biener Date: Mon, 16 Aug 2021 15:33:45 +0200 Message-ID: Subject: Re: 'hash_map>' To: Thomas Schwinge Cc: GCC Development , Jonathan Wakely , Martin Sebor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 13:33:59 -0000 On Mon, Aug 16, 2021 at 2:44 PM Thomas Schwinge w= rote: > > Hi! > > On 2021-08-09T12:02:02+0200, Richard Biener via Gcc wro= te: > > On Fri, Aug 6, 2021 at 6:58 PM Thomas Schwinge wrote: > >> So I'm trying to do some C++... ;-) > >> > >> Given: > >> > >> /* A map from SSA names or var decls to record fields. */ > >> typedef hash_map field_map_t; > >> > >> /* For each propagation record type, this is a map from SSA names = or var decls > >> to propagate, to the field in the record type that should be us= ed for > >> transmission and reception. */ > >> typedef hash_map record_field_map_t; > >> > >> Thus, that's a 'hash_map>'. (I may do that= , > >> right?) Looking through GCC implementation files, very most of all us= es > >> of 'hash_map' boil down to pointer key ('tree', for example) and > >> pointer/integer value. > > > > You could use > > > > hash_map record_field_map_p; > > vec maps; > > > > and record the index into maps which you record the actual maps. > > Ugh ;-) -- yes, if I remember correctly, I've spotted that pattern in a > few GCC source files. > > > Alternatively use hash_map > > ACK; see commit 049eda8274b7394523238b17ab12c3e2889f253e "Avoid 'GTY' use > for 'gcc/omp-oacc-neuter-broadcast.cc:field_map'". (So, actually don't > change 'record_field_map_t' at this time.) > > > > Note your code will appear to work until you end up in the situation > > where record_field_map_t is resized because hash-map doesn't > > std::move elements when re-hashing. > > I'm not understanding, would you please provide some more detail here? > > Did you mean "resizing" instead of "re-hashing"? yes > If the latter, then > yes, it does 'std::move' them (via 'hash_table::expand') -- see (your > own) commit 4b9d61f79c0c0185a33048ae6cc72269cf7efa31 "add move CTOR to > auto_vec, use auto_vec for get_loop_exit_edges". But I guess I > completely misunderstood? Oh, indeed I fixed that ;) But then hash_table doesn't have a move CTOR ..= . I bet that it also was incomplete in some other way (I ended up not actuall= y needing this std::move stuff for hash_map/autp_vec after all...). But the = DTOR piece should be OK with a suitable traits class I think (the ::remove trait member should call it). > > > Gr=C3=BC=C3=9Fe > Thomas > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 2= 01, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellsc= haft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955