On Wed, Oct 14, 2015 at 5:53 PM, Jeff Law <l...@redhat.com> wrote: > On 10/14/2015 09:43 AM, Jan Hubicka wrote: >>>>>> >>>>>> I think he asked for trivial forward threads though due to repeated >>>>>> tests. >>>>>> I hacked FRE to do this (I think), but maybe some trivial cleanup >>>>>> opportunities >>>>>> are still left here. Honza? >> >> >> Well, unthreaded jumps quite confuse profile prediction and create >> profiles >> that we can't fix later. An of course they count in time (and size >> sometimes) >> estimates. >> >> From cases I commonly see it is the usual lazyness of repeated tests >> comming >> from early inlining/macro expansion and also C++ love to introduce >> >> if (ptr != NULL) >> ptr2 = &ptr->foo; >> else >> ptr2 = NULL >> >> for instances of multiple inheritance. usually ptr is known to be >> non-NULL. >> And also cases where if is uses to check individual cases without having >> proper >> esles. > > Yea. I still see a variety of trivial jump threads lying around early in > the pipeline. > > The nice thing about the backwards walking stuff in this context is we can > control how hard it looks for jump threads much better. > > The difficult thing is it's not currently prepared to find the implicit sets > from conditionals. Re-using the ASSERT_EXPR mechanisms from vrp may be the > solution. I haven't tried that yet, but it's in the back of my mind for > solving that class of problems cleanly.
Now that FRE performs a DOM walk when value-numbering and considers temporary equivalences (well, ok, it does not, it only records known true/false predicates) one could implement forward jump-threading quite easily in FRE I think (the value-numbering already will work like if we have threaded the jump, we just won't do the actual threading / path duplication). Do you have any actual testcases I can have a look at? I suppose running DOM after FRE1 and looking for "extra" optimizations done on the testsuite would do the trick but is also likely to just uncover "complex" cases. Richard. > > > jeff >
