[prev in list] [next in list] [prev in thread] [next in thread]
List: gcc
Subject: Re: Can we replace uses of vec<TYPE, va_gc> with vec<TYPE> in the backwards threader?
From: Jeff Law <law () redhat ! com>
Date: 2017-08-30 14:32:52
Message-ID: 98a2815c-9dd8-5a4d-bac6-ee7a6407d1cf () redhat ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic