On Tue, 10 Dec 2019, Jan Hubicka wrote:
> > I would recommend to make these variables uint64_t, then you can simply do
> >
> > tp_first_run_a--;
> > tp_first_run_b--;
> >
> > making 0 wrap around to UINT64_MAX. Then they will naturally sort after all
> > other nodes.
>
> Then we would still have to watch the overflow before returning? I
> actually find the condtional sort of more readable than intentional wrap
> around the range, so I kept it in the code espeically because I made the
> value 32bit again and without this trick I no longer need to watch
> overflows.
For int-typed timestamps, you'd need to warp 0 to INT_MAX, e.g. like this:
tp_first_run_a = (tp_first_run_a - 1) & INT_MAX;
tp_first_run_b = (tp_first_run_b - 1) & INT_MAX;
which keeps them in 0..INT_MAX range so 'return tp_first_run_a - tp_first_run_b'
still works.
> > > + /* Output functions in RPO so callers get optimized before callees.
> > > This
> > > + makes ipa-ra and other propagators to work.
> > > + FIXME: This is far from optimal code layout. */
> >
> > I think this should have said "callees get optimized before callers".
>
> Indeed.
So technically this would be just postorder, not RPO :)
> --- cgraph.c (revision 279093)
> +++ cgraph.c (working copy)
> @@ -3074,6 +3074,11 @@ cgraph_node::verify_node (void)
> inlined_to->count.debug ();
> error_found = true;
> }
> + if (tp_first_run < 0)
> + {
> + error ("tp_first_run must be positive");
> + error_found = true;
> + }
"non-negative"?
Alexander
