This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Patch for switch elimination (PR 54742)
- From: Jeff Law <law at redhat dot com>
- To: Sebastian Pop <sebpop at gmail dot com>, Steve Ellcey <sellcey at mips dot com>
- Cc: Richard Biener <richard dot guenther at gmail 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: Wed, 13 Aug 2014 15:06:45 -0600
- 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>
On 08/13/14 14:55, Sebastian Pop wrote:
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.
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?
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.