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.
jeff
