Re: Can we replace uses of vec<TYPE, va_gc> with vec<TYPE> in the backwards threader?

[Jeff Law <law at redhat dot com>]

On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
> Hi!
> 
> I'm looking at tree-ssa-threadbackward.c, where we pass around a lot
> of "vec<basic_block, va_gc>" pointers representing a path through a
> flow graph.
> 
> I'm wondering why we use va_gc, when AFAICT, the paths are local to
> the pass, and we can easily free them with path.release() at the end
> of the pass.  For that matter, it seems like we're already going
> through the trouble of freeing them manually:
> 
>   vec<basic_block, va_gc> *bb_path;
>   vec_alloc (bb_path, 10);
> ...
>   vec_free (bb_path);
> 
> Am I missing something wrt vl_embed and vl_ptr magic, or would it be
> acceptable to replace all these vec<basic_block, va_gc> with
> vec<basic_block> and use the stack?  First because the GC has
> additional overhead, and second because vec<TYPE, va_gc> is fugly.
> 
> If so, I'm assuming that similar things can be done throughout the
> compiler.  Why use GC, when a vector is local to a pass?
Probably just an oversight on my part when reviewing Sebastian's code.
It's also possible refactorings have brought the scope of the vectors to
a function.  There shouldn't be anything overly tricky going on with
that, so give it a try.

If you're looking for further cleanups, pulling the rest of the FSM bits
out of tree-ssa-threadupdate.c is ripe.  In particular this loop:

 /* Jump-thread all FSM threads before other jump-threads.  */
  for (i = 0; i < paths.length ();)
[ ... ]

If that was to get pulled out and moved into tree-ssa-threadbackwards.c,
then you can probably skip the step that converts the vector of blocks
into a vector of jump_thread_edge which then gets turned into an array
of blocks.  In theory you just turn the vector of blocks into an array
of blocks to match the api for duplicate_thread_path.

Jeff