On Fri, Sep 1, 2017 at 10:16 PM, Trevor Saunders <tbsau...@tbsaunde.org> wrote:
> On Fri, Sep 01, 2017 at 04:18:20PM -0400, Aldy Hernandez wrote:
>> Hi.
>>
>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>> The main gist of the patch is making the path vectors live in the
>> heap, not GC.  But I also cleaned up some comments to reflect reality,
>> and renamed VAR_BB which could use a more meaningful name.  Finally, I
>> abstracted some common code to
>> register_jump_thread_path_if_profitable() in preparation for some
>> upcoming work by me :).
>>
>> Tested on x86-64 Linux.
>>
>> OK?
>
>  check_subpath_and_update_thread_path (basic_block last_bb, basic_block 
> new_bb,
>                                       hash_set<basic_block> *visited_bbs,
> -                                     vec<basic_block, va_gc> *&path,
> +                                     vec<basic_block> &path,
>                                       int *next_path_length)
>  {
>    edge e;
>    int e_count = 0;
>    edge_iterator ei;
> -  vec<basic_block, va_gc> *next_path;
> -  vec_alloc (next_path, 10);
> +  vec<basic_block> next_path = vNULL;
>
> I believe all paths out of this scope release next_path, so it can be
> said the scope owns this vector and you could use auto_vec here.

I originally wanted plain vec<> so it could be passed around to other
work I'm doing on the threader, but I see that auto_vec<> inherits
from vec<T, va_heap>, and the default vec<> is just vec<T, va_heap,
va_heap::default_layout>.  So...it's all the same, and will work
seamlessly.

Thanks.  Will do.

>
> @@ -776,9 +786,8 @@ find_jump_threads_backwards (basic_block bb, bool speed_p)
>    if (!name || TREE_CODE (name) != SSA_NAME)
>      return;
>
> -  vec<basic_block, va_gc> *bb_path;
> -  vec_alloc (bb_path, 10);
> -  vec_safe_push (bb_path, bb);
> +  vec<basic_block> bb_path = vNULL;
>
> same holds here I think.

Will do.

>
> +  bb_path.safe_push (bb);
>    hash_set<basic_block> *visited_bbs = new hash_set<basic_block>;
>
>    btw I don't see why this hash table can't be just a hash_table<> and
>    live on the stack.

Very good point.  Thanks.

Reply via email to