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: Aldy Hernandez <aldyh at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, richard dot sandiford at linaro dot org
- Date: Tue, 5 Sep 2017 08:32:34 -0400
- 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> <firstname.lastname@example.org>
On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law <email@example.com> wrote:
> On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
> 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.
Hmm, it seems that the above loop you mention in
thread_through_all_blocks() still needs to iterate over a global
vec<jump_thread_edge *> vector ("paths"). So we still need to go
through a vector of jump edges.