This is the mail archive of the
mailing list for the GCC project.
Re: Can we replace uses of vec<TYPE, va_gc> with vec<TYPE> in the backwards threader?
- From: Jeff Law <law at redhat dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, richard dot sandiford at linaro dot org
- Date: Wed, 30 Aug 2017 08:32:52 -0600
- Subject: Re: Can we replace uses of vec<TYPE, va_gc> with vec<TYPE> in the backwards threader?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1C32C13A47
- References: <CAGm3qMVhMEwHE0+MpBix8UXvNfsX+A2c3s5kGRaA5jtYfiX7SQ@mail.gmail.com>
On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
> 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.