This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Can we replace uses of vec<TYPE, va_gc> with vec<TYPE> in the backwards threader?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Richard Sandiford <richard dot sandiford at linaro dot org>, Jeff Law <law at redhat dot com>
- Date: Wed, 30 Aug 2017 14:30:59 +0200
- Subject: Re: Can we replace uses of vec<TYPE, va_gc> with vec<TYPE> in the backwards threader?
- Authentication-results: sourceware.org; auth=none
- References: <CAGm3qMVhMEwHE0+MpBix8UXvNfsX+A2c3s5kGRaA5jtYfiX7SQ@mail.gmail.com>
On Wed, Aug 30, 2017 at 12:41 PM, Aldy Hernandez <aldyh@redhat.com> 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 history and no good reason. Feel free to make them heap
vectors.
Richard.
> Thanks.
> Aldy