public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Lawrence Crowl <crowl@googlers.com>
Cc: gcc-patches List <gcc-patches@gcc.gnu.org>
Subject: Re: [patch] Hash table changes from cxx-conversion branch
Date: Thu, 28 Mar 2013 09:34:00 -0000	[thread overview]
Message-ID: <CAFiYyc2tdPp7oZ_XbWZNHTS0MbHRnw8iG1pNw33KcuMZO_gvCA@mail.gmail.com> (raw)
In-Reply-To: <CAGqM8fZjzZhW=KxjA0EwHbqDq3D00sq50A=eZbSkBqSoTDnTEg@mail.gmail.com>

On Wed, Mar 27, 2013 at 5:44 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> On 3/27/13, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Mar 23, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
>> > This patch is a consolodation of the hash_table patches to the
>> > cxx-conversion branch.
>> >
>> > Update various hash tables from htab_t to hash_table.
>> > Modify types and calls to match.
>>
>> Ugh.  Can you split it up somewhat ... like split target bits
>> away at least?  Targets may prefer to keep the old hashes for
>> ease of branch maintainance.
>
> I will do that.
>
>> > * tree-ssa-live.c'var_map_base_init::tree_to_index
>> >
>> > New struct tree_int_map_hasher.
>>
>> I think this wants to be generalized - we have the common
>> tree_map/tree_decl_map and tree_int_map maps in tree.h - those
>> (and its users) should be tackled in a separate patch by providing
>> common hashtable trails implementations.
>
> I will investigate for a separate patch.
>
>> > Remove unused:
>> >
>> > htab_t scop::original_pddrs
>> > SCOP_ORIGINAL_PDDRS
>> >
>> > Remove unused:
>> >
>> > insert_loop_close_phis
>> > insert_guard_phis
>> > debug_ivtype_map
>> > ivtype_map_elt_info
>> > new_ivtype_map_elt
>>
>> Unused function/type removal are obvious changes.
>>
>> > Remove unused:
>> > dse.c bitmap clear_alias_sets
>> > dse.c bitmap disqualified_clear_alias_sets
>> > dse.c alloc_pool clear_alias_mode_pool
>> > dse.c dse_step2_spill
>> > dse.c dse_step5_spill
>> > graphds.h htab_t graph::indices
>>
>> See above.
>
> It wasn't obvious that the functions could be removed.  :-)
>
> Are you saying you don't want these notations in the description?

No, I was saying that removal of unused functions / types should be
committed separately and do not need approval as they are obvious.
If they are not obvious (I didn't look at that patch part), then posting
separately still helps ;)

Thanks,
Richard.

> --
> Lawrence Crowl

  parent reply	other threads:[~2013-03-28  9:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-23 22:36 Lawrence Crowl
2013-03-26 23:53 ` Lawrence Crowl
2013-03-27  9:38 ` Richard Biener
2013-03-27 16:44   ` Lawrence Crowl
2013-03-28  3:45     ` Lawrence Crowl
2013-03-28  9:34     ` Richard Biener [this message]
2013-03-31 22:17       ` Lawrence Crowl
2013-04-09  1:54         ` Lawrence Crowl
2013-04-09 11:13           ` Richard Biener
     [not found]   ` <CAGqM8fZC_DG2u17WD=tnnQq3nJ3MtAyJzUBU5+4D4WME2Sh-rQ@mail.gmail.com>
2013-04-24 23:18     ` Lawrence Crowl
2013-04-25 14:19       ` Richard Biener
2013-04-26 10:57         ` Lawrence Crowl
2013-04-25 21:47       ` Diego Novillo
2013-04-26 11:00         ` Lawrence Crowl
2013-03-27 13:59 ` Martin Jambor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc2tdPp7oZ_XbWZNHTS0MbHRnw8iG1pNw33KcuMZO_gvCA@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=crowl@googlers.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).