This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 09/05/2017 06:32 AM, Aldy Hernandez wrote:
> On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law <law@redhat.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.
It's just finding the backwards paths that we converted into the
jump_thread_edge form.  Then we iterate over the edges in the path to
build an array of blocks.

So instead of converting our vec of blocks into a jump_thread_edge, we
just keep the vec of blocks when we pull that loop out of
tree-ssa-threadupdate.c.


That would also mean the immediately following loop should be dead.

Unless I'm missing something?!?

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]