This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/3] Enhance dumps of IVOPTS


On Thu, May 12, 2016 at 1:13 PM, Martin LiÅka <mliska@suse.cz> wrote:
> On 05/10/2016 03:16 PM, Bin.Cheng wrote:
>> Another way is to remove the use of id for struct iv_inv_expr_ent once
>> for all.  We can change iv_ca.used_inv_expr and cost_pair.inv_expr_id
>> to pointers, and rename iv_inv_expr_ent.id to count and use this to
>> record reference number in iv_ca.  This if-statement on dump_file can
>> be saved.  Also I think it simplifies current code a bit.  For now,
>> there are id <-> struct maps for different structures in IVOPT which
>> make it not straightforward.
>
> Hi.
>
> I'm sending second version of the patch. I tried to follow your advices, but
> because of a iv_inv_expr_ent can simultaneously belong to multiply iv_cas,
> putting counter to iv_inv_expr_ent does not works. Instead of that, I've
> decided to replace used_inv_expr with a hash_map that contains used inv_exps
> and where value of the map is # of usages.
>
> Further questions:
> + iv_inv_expr_ent::id can be now removed as it's used just for purpose of dumps
> Group 0:
>   cand  cost    scaled  freq    compl.  depends on
>   5     2       2.00    1.000
>   6     4       4.00    1.001    inv_expr:0
>   7     4       4.00    1.001    inv_expr:1
>   8     4       4.00    1.001    inv_expr:2
>
> That can be replaced with print_generic_expr, but I think using ids makes the dump
> output more clear.
I am okay with keeping id.  Could you please dump all inv_exprs in a
single section like
<Invariant Exprs>:
inv_expr 0: print_generic_expr
inv_expr 1: ...

Then only dump the id afterwards?

>
> + As check_GNU_style.sh reported multiple 8 spaces issues in hunks I've touched, I decided
> to fix all 8 spaces issues. Hope it's fine.
>
> I'm going to test the patch.
> Thoughts?

Some comments on the patch embedded.

>
> +/* Forward declaration.  */
Not necessary.
> +struct iv_inv_expr_ent;
> +

>
>  /* Stores EXPR in DATA->inv_expr_tab, and assigns it an inv_expr_id.  */
>
> -static int
> +static iv_inv_expr_ent *
>  get_expr_id (struct ivopts_data *data, tree expr)
We are not returning id any more, maybe rename to record_inv_expr or else.

>  {
>    struct iv_inv_expr_ent ent;
> @@ -4806,13 +4809,13 @@ get_expr_id (struct ivopts_data *data, tree expr)
>    ent.hash = iterative_hash_expr (expr, 0);
>    slot = data->inv_expr_tab->find_slot (&ent, INSERT);
>    if (*slot)
> -    return (*slot)->id;
> +    return *slot;
>
>    *slot = XNEW (struct iv_inv_expr_ent);
>    (*slot)->expr = expr;
>    (*slot)->hash = ent.hash;
>    (*slot)->id = data->max_inv_expr_id++;
> -  return (*slot)->id;
> +  return *slot;
This could be changed to
  if (!*slot)
    {
      //new and insert
    }
  return *slot;
>  }
>
>  /* Returns the pseudo expr id if expression UBASE - RATIO * CBASE
> @@ -4820,10 +4823,10 @@ get_expr_id (struct ivopts_data *data, tree expr)
>     ADDRESS_P is a flag indicating if the expression is for address
>     computation.  */
>
> -static int
> +static iv_inv_expr_ent *
>  get_loop_invariant_expr_id (struct ivopts_data *data, tree ubase,
> -                            tree cbase, HOST_WIDE_INT ratio,
> -                            bool address_p)
> +                tree cbase, HOST_WIDE_INT ratio,
> +                bool address_p)
Rename function name here too.
>  {

> @@ -5988,9 +5992,9 @@ determine_group_iv_costs (struct ivopts_data *data)
>            if (group->cost_map[j].depends_on)
>          bitmap_print (dump_file,
>                    group->cost_map[j].depends_on, "","");
> -          if (group->cost_map[j].inv_expr_id != -1)
> +        if (group->cost_map[j].inv_expr != NULL)
>          fprintf (dump_file, " inv_expr:%d",
> -             group->cost_map[j].inv_expr_id);
> +             group->cost_map[j].inv_expr->id);
Dump inv_expr in another column thus it won't appear under depends_on
in dump.  Also make it preceding depends_on which is a bitmap.

While we are on this one before the other two, could you please make
this independent so it can be committed after rework?

Thanks,
bin

>
> Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]