From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128729 invoked by alias); 14 Nov 2017 12:32:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 127873 invoked by uid 89); 14 Nov 2017 12:32:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Nov 2017 12:32:35 +0000 Received: by mail-wm0-f65.google.com with SMTP id r68so17834155wmr.0 for ; Tue, 14 Nov 2017 04:32:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B9+Nwt/RvnD4Hr9Nd1J9XJhmB+3Ra2d2jhDbpejtQqc=; b=JKnjuC0eQ2C3Y/LvH4k2C5VejaUha8bThkBfYShgvAJCUP1jUvSIPXYz7TFNmVjXi9 9lmXxqcuylOLkzgDi/f9tBrcjnn6cW3srmMPdrHbVcsWseX/U5hC+NRqa3D/BaBu00eI PetSygr/tHjgUAkXJqwn9+uUAMX8IoK5vjXVKPv6AuYa+p0dTcSrDv5rDtzOhIA46xDL bPEc3EwG/40vvAiIUTHRs6fW8sVSFDS/E4WuQza7jE1669JRNxctO3AzlNUPAcMIQR/K dkCGzWzgJi8YWai3Ba5WN1sFFINiolcJ8E6H2xLfJTHzUQoRs+cpUlnBU6dlahCnRmc5 cCiA== X-Gm-Message-State: AJaThX5TrG2yR4/TB1gc/RFY8GoU+R2CujrgfA66JUW559ENUzZtXqZW Q9munwUJ2N1WCOK6rZGOHSEjAFEBSubGfSd7rYH9Ag== X-Google-Smtp-Source: AGs4zMaXCr5ms9ltLYxH1lhTMCBC4Qwt0hN3d/5qDEcYOKP9nNZFw7SAi1HmaF8ze417niitrlgtdIYg66oeMFu9qr8= X-Received: by 10.80.217.15 with SMTP id t15mr17542506edj.217.1510662753752; Tue, 14 Nov 2017 04:32:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Tue, 14 Nov 2017 04:32:33 -0800 (PST) In-Reply-To: References: From: Richard Biener Date: Tue, 14 Nov 2017 12:55:00 -0000 Message-ID: Subject: Re: RFA (hash-map): PATCH to support GTY((cache)) with hash_map To: Jason Merrill Cc: gcc-patches List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01070.txt.bz2 On Fri, Sep 15, 2017 at 11:45 PM, Jason Merrill wrote: > The hash_map interface is a lot more convenient than that of > hash_table for cases where it makes sense, but there hasn't been a way > to get the ggc_cache_remove behavior with a hash_map. In other words, > not marking elements during the initial ggc marking phase, but maybe > marking them during the clear_caches phase based on keep_cache_entry. > > This patch implements that by: > > Adding a ggc_maybe_mx member function to ggc_remove, and overriding > that instead of ggc_mx in ggc_cache_remove. > Calling H::ggc_maybe_mx instead of H::ggc_mx in gt_ggc_mx (hash_table *). > Calling H::ggc_mx in gt_cleare_caches (hash_table *) rather than > relying on an extern declaration of a plain function that cannot be > declared for hash_map::hash_entry. > Adding ggc_maybe_mx and keep_cache_entry to hash_map::hash_entry. > Adding gt_cleare_cache for hash_map. > Adding a boolean constant to the hash-map traits indicating whether we > want the cache behavior above. > > I then define a typedef tree_cache_map to use this functionality, and > use it in a few places in the C++ front end. > > Tested x86_64-pc-linux-gnu, OK for trunk? Ok. Richard.