On Thu, Aug 18, 2022 at 1:10 PM Aldy Hernandez wrote:
>
> On Thu, Aug 18, 2022, 11:34 Richard Biener wrote:
> >
> > On Thu, Aug 18, 2022 at 9:58 AM Aldy Hernandez wrote:
> > >
> > > FWIW, here is a rebased version with the latest trunk.
> > >
> > > There are no regressions, or differences in thr
On Thu, Aug 18, 2022, 11:34 Richard Biener wrote:
>
> On Thu, Aug 18, 2022 at 9:58 AM Aldy Hernandez wrote:
> >
> > FWIW, here is a rebased version with the latest trunk.
> >
> > There are no regressions, or differences in threading counts, and the
> > performance change is negligible.
>
> +{
On Thu, Aug 18, 2022 at 9:58 AM Aldy Hernandez wrote:
>
> FWIW, here is a rebased version with the latest trunk.
>
> There are no regressions, or differences in threading counts, and the
> performance change is negligible.
+{
+ mark_dfs_back_edges ();
+
+ if (flag_checking)
+
solver,
> -// and calculate the ranges along the path.
> +// Calculate the set of exit dependencies for a path and statement to
> +// be simplified. This is different than the
> +// compute_exit_dependencies in the path solver because the forward
> +// threader asks questions about statements not
These are a bunch of cleanups inspired by Richi's suggestion of making
path_range_query standalone, instead of having to call
compute_ranges() for each path.
I've made the ranger need explicit, and moved the responsibility for
its creation to the caller.
I've also investigated and documented why
