This is the mail archive of the gcc-patches@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: [PATCH 3/3] Loop flattening on loop-SSA.


On Mon, Nov 15, 2010 at 11:42 PM, Sebastian Pop <sebpop@gmail.com> wrote:
> On Mon, Nov 8, 2010 at 10:09, Richard Guenther <rguenther@suse.de> wrote:
>>> > This function should be in cfgloop.c and implemented in simpler
>>> > form, like
>>> >
>>> > void
>>> > cancel_subloops (struct loop *loop)
>>> > {
>>> > ?while (loop->inner)
>>> > ? ?cancel_loop_tree (loop->inner);
>>> > }
>>> >
>>>
>>> Ok I will move this function to cfgloop.c. ?However, if I don't think
>>> we can simplify it further without extra storage: if I write the
>>> simplified form like this:
>>>
>>> void
>>> cancel_subloops (struct loop *loop)
>>> {
>>> ? loop_p x = loop->inner;
>>>
>>> ? while (x)
>>> ? ? {
>>> ? ? ? cancel_loop_tree (x);
>>> ? ? ? x = x->next;
>>> ? ? }
>>> }
>>>
>>> this won't work, as the loop x gets first canceled and then we try to
>>> access x->next and this will produce a segfault.
>>
>> Which is why my suggested variant would work, no?
>>
>
> Your simplified variant does not handle sibling loops: for example, it
> wouldn't cancel loop_3 during a cancel_subloops (loop_1) in
>
> loop_1
> ?loop_2
> ?end_2
>
> ?loop_3
> ?end_3
> end_1
>
> you have to iterate on loop->next to cancel loop_3, and your variant
> doesn't do that: cancel_loop_tree "Cancels LOOP and all its subloops."
> and that does not include sibling loops.

Sure it would - cancel_loop_tree (loop->inner) makes loop->inner->next
loop->inner.  This is why cancel_loop_tree works in the first place.

Richard.

> Sebastian
>


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