On Tue, Mar 23, 2021 at 8:55 AM bin.cheng <bin.ch...@linux.alibaba.com> wrote: > > > > In the patch, I just duplicated and created new function > > > loop_first_rev_post_order_compute_fn. > > > I am not sure if I should change the original function > > > pre_and_rev_post_order_compute_fn > > > (maybe not at this stage)? I am neither sure about the name, though > > > haven't got a better one. > > > Any comment is appreciated? > > > > So your new function seems to do what rev_post_order_and_mark_dfs_back_seme > > does > > when you specify for_iteration = true. Specifically that function then does > > > > If FOR_ITERATION is true then compute an RPO where SCCs form a > > contiguous region in the RPO array. > > Right, this is exactly what I need. Attachment is the updated patch. > Bootstrap and test on x86_64.
OK - Thank you. > > > > it in particular should handle the situation well where there are multiple > > exits > > from a loop to different outer loops (consider a switch stmt exiting to > > the immediate outer or to the next outer loop) - something your patch > > likely still handles "randomly" (though we of course generally do not handle > > such exits well). > > > > The idea of the rev_post_order_and_mark_dfs_back_seme algorithm is to > > treat SCCs as single nodes for the "outermost" RPO walk and then > > continuously expand SCCs from outer to inner. > > > > So for the testcase I'm quite sure using the this function for computing > > the RPO would work but extra thoughts are appreciated. > Maybe another more straightforward or easier to understand function name? Heh ;) I suppose we could wrap it with an easier to grok name for the callers not wanting to apply it on a region. Richard. > Thanks, > bin > > > > Thanks, > > Richard. > >
