On Wed, Aug 13, 2014 at 11:06 PM, Jeff Law <l...@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 > >