This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Allow FSM to thread single block cases too
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 15 Oct 2015 10:28:32 +0200
- Subject: Re: [PATCH] Allow FSM to thread single block cases too
- Authentication-results: sourceware.org; auth=none
- References: <561CF734 dot 7090802 at redhat dot com> <CAFiYyc05ZbhMHAfaP1u39L_c8jWQA6rchoqD2z2Sm8Z0ObwmjQ at mail dot gmail dot com> <CAFiYyc368RDUDebLVff0C1PhyvPiOnvxHwcj_j0Z8XFZOwzUTw at mail dot gmail dot com> <561E4DAD dot 9060702 at redhat dot com> <CAFiYyc37QvGeKJGc_LQNYXOs=vQh4qZXGAns+W+E+jcc3=Zvpw at mail dot gmail dot com> <20151014154341 dot GC16672 at kam dot mff dot cuni dot cz> <561E7A7D dot 5000407 at redhat dot com>
On Wed, Oct 14, 2015 at 5:53 PM, Jeff Law <law@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
>