This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Improving jump-thread pass for PR 54742
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>,Sebastian Pop <sebpop at gmail dot com>
- Cc: Steve Ellcey <sellcey at mips dot com>,James Greenhalgh <james dot greenhalgh at arm dot com>,GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 09 Dec 2014 20:43:41 +0100
- Subject: Re: [Patch] Improving jump-thread pass for PR 54742
- Authentication-results: sourceware.org; auth=none
- References: <20141125172945 dot GA31146 at f1 dot c dot bardezibar dot internal> <20141125211618 dot GA32340 at f1 dot c dot bardezibar dot internal> <547CD855 dot 50501 at redhat dot com> <20141204110428 dot GC18834 at f1 dot c dot bardezibar dot internal> <20141204142956 dot GD18834 at f1 dot c dot bardezibar dot internal> <548211B9 dot 6020307 at redhat dot com> <20141206134728 dot GA29926 at f1 dot c dot bardezibar dot internal> <20141206192113 dot GB29926 at f1 dot c dot bardezibar dot internal> <1418075397 dot 2196 dot 76 dot camel at ubuntu-sellcey> <CAFiYyc0vm39Od7xEbAyu-6Uefv2YKQNVQ3wmX_f1hBcAek8ADg at mail dot gmail dot com> <20141209173842 dot GA31443 at f1 dot c dot bardezibar dot internal> <548741F4 dot 1080202 at redhat dot com>
On December 9, 2014 7:39:48 PM CET, Jeff Law <law@redhat.com> wrote:
>On 12/09/14 10:38, Sebastian Pop wrote:
>> Richard Biener wrote:
>>> On Mon, Dec 8, 2014 at 10:49 PM, Steve Ellcey <sellcey@mips.com>
>wrote:
>>>> expected? Should this test also check flag_thread_jumps? Or
>should
>>>> that be getting checked somewhere else?
>>>
>>> -fthread-jumps is an RTL optimization flag and ignored on GIMPLE.
>>
>> Does it make sense to add a -f[no-]tree-thread-jumps to
>enable/disable the tree
>> jump threading? I could also add -f[no-]tree-fsm-thread-jumps.
>Opinions?
>Our option handling is a bit of a mess if we look at it from the user
>standpoint. Given that the vast majority of jump threading happens on
>gimple, ISTM that -f[no-]thread-jumps ought to be controlling the
>gimple
>implementation. One could easily argue that the user doesn't really
>care about where in the pipeline the optimization is implemented.
>
>My vote would be to just make -fthread-jumps control both RTL and
>gimple
>jump threading.
Works for me.
>
>>
>> On the llvm test-suite, I have seen one ICE with my fsm jump-thread
>patch.
>> This patch fixes the problem:
>>
>> diff --git a/gcc/tree-ssa-threadupdate.c
>b/gcc/tree-ssa-threadupdate.c
>> index 12f83ba..f8c736e 100644
>> --- a/gcc/tree-ssa-threadupdate.c
>> +++ b/gcc/tree-ssa-threadupdate.c
>> @@ -2564,6 +2564,7 @@ thread_through_all_blocks (bool
>may_peel_loop_headers)
>> FOR_EACH_LOOP (loop, LI_FROM_INNERMOST)
>> {
>> if (!loop->header
>> + || !loop_latch_edge (loop)
>> || !bitmap_bit_p (threaded_blocks, loop->header->index))
>> continue;
>>
>> retval |= thread_through_loop_header (loop,
>may_peel_loop_headers);
>>
>> Ok to commit after regstrap?
>This seems to be indicating that we have with no edge from the latch
>block to the header block. I'd like to know better how we got into
>that
>state.
It Also returns null for loops with multiple latches. So the patch looks OK for me.
Thanks,
Richard.
>Also, a test for the GCC testsuite would be good. I have no idea what
>license covers the LLVM testsuite. But given a good analysis of the
>problem we may be able to write a suitable test independent of the LLVM
>
>test.
>
>jeff