This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Patch for switch elimination (PR 54742)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Sebastian Pop <sebpop at gmail dot com>, Steve Ellcey <sellcey at mips dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, james dot greenhalgh at arm dot com, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 14 Aug 2014 12:32:32 +0200
- Subject: Re: RFC: Patch for switch elimination (PR 54742)
- Authentication-results: sourceware.org; auth=none
- References: <1407865606 dot 2601 dot 74 dot camel at ubuntu-sellcey> <53EA5D74 dot 9020809 at redhat dot com> <47b32a49-298e-44f0-b84b-b8f664847a67 at email dot android dot com> <53EA7BD0 dot 1030901 at redhat dot com> <1407883486 dot 2601 dot 86 dot camel at ubuntu-sellcey> <20140813205519 dot GB23343 at instance-1 dot c dot bardezibar dot internal> <53EBD365 dot 4040100 at redhat dot com>
On Wed, Aug 13, 2014 at 11:06 PM, Jeff Law <law@redhat.com> wrote:
> On 08/13/14 14:55, Sebastian Pop wrote:
>>
>> Steve Ellcey wrote:
>>>
>>> +/* This file implements an optimization where, when a variable is set
>>> + to a constant value and there is a path that leads from that
>>> definition
>>> + to a switch statement that uses that variable as its controlling
>>> expression
>>> + we duplicate the blocks on this path and change the jump to the
>>> switch
>>> + statement with a direct jump to the label of the switch block that
>>> control
>>> + would goto based on the value of the variable. This can come up in
>>> + loops/switch statements that implement state machines.
>>
>>
>> Can you explain why the jump-threading pass cannot do this? Why do we
>> need
>> another pass to handle a corner case that jump-thread does not catch yet?
>
> I'm pretty sure jump threading *could* handle it, but after looking at the
> full testcase when it was posted, I'm not sure it's *wise* to handle this in
> jump threading.
>
> The core issue is we have to look even deeper into the CFG than was
> originally envisioned and do quite a bit more block duplication than was
> originally envisioned. That's going to have a notable compile-time cost
> (and to a lesser extent issues around codesize).
>
> It's unfortunate that the testcase when we first looked at this was
> over-simplified and not actually representative of what happens in Coremark.
> Had I seen the Coremark testcase, I probably wouldn't have suggested we
> tackle the problem in jump threading and the extensions I made to jump
> threading would _not_ have included aggressively following backedges in the
> CFG.
>
> You'll note in a separate thread Steve and I discussed this during Cauldron
> and it was at my recommendation Steve resurrected his proof of concept
> plugin and started beating it into shape.
But do we really want a pass just to help coremark?
Richard.
> jeff
>
>