Earlier quoted context omitted.
(disclaimer: current V8 team member replying to senior ex-V8 team member) I'd say there were a lot more things problematic in practice with SoN than not relaxing effect edges enough - I'd argue that the bigger problem was that a single effect chain was not enough to represent the flexibility that SoN promised, while keeping the costs, and getting that flexibility would mean effectively extending the effect chain to o…
Well obviously I don't think that you're a bunch of dummies so please don't throw out strawmen like that. I don't know if Cliff is on the same page w.r.t. how much speculation is necessary (and when) to make JS go fast. In particular, inserting speculative guards has the nice property of improving downstream information for dominated control flow paths. Dominated control flow paths are few and far between when the co…
The acyclic e-graph: Cranelift's mid-end optimizer
21–25 of 25 posts
Re: The acyclic e-graph: Cranelift's mid-end optimizer
#22This is really cool. Thanks for the write-up, Chris! I kept waiting for "sea of nodes with CFG" to be shortened to SeaFG, and it never happened. I guess maybe it's ambiguous out loud.
Re: The acyclic e-graph: Cranelift's mid-end optimizer
#23This is really cool. Thanks for the write-up, Chris! I kept waiting for "sea of nodes with CFG" to be shortened to SeaFG, and it never happened. I guess maybe it's ambiguous out loud.
(And thanks!)
Re: The acyclic e-graph: Cranelift's mid-end optimizer
#24> While that kind of flexibility is tempting, it comes with a significant complexity tax as well: it means that reasoning through and implementing classical compiler analyses and transforms is more difficult, at least for existing compiler engineers with their experience, because the IR is so different from the classical data structure (CFG of basic blocks). The V8 team wrote about this difficulty recently as support…
Well it's hard to summarize what I said in the Coffee Compiler club chat in a HN comment, but there were a number of things that went wrong there. I half agree with Cliff and half agree with the V8 blogpost. TurboFan evolved into a very complicated compiler that made a number of things harder on itself that it should have been. The sea of nodes is just extending SSA renaming on values to both control and effects. Eff…
My point was towards more to the reasoning "V8 moved away from it, thus bad" that usually comes out of such remarks, when in a reality it is much more nuanced that this.
As you kind of nicely put out.
Re: The acyclic e-graph: Cranelift's mid-end optimizer
#25Earlier quoted context omitted.
(disclaimer: current V8 team member replying to senior ex-V8 team member) I'd say there were a lot more things problematic in practice with SoN than not relaxing effect edges enough - I'd argue that the bigger problem was that a single effect chain was not enough to represent the flexibility that SoN promised, while keeping the costs, and getting that flexibility would mean effectively extending the effect chain to o…
Well obviously I don't think that you're a bunch of dummies so please don't throw out strawmen like that. I don't know if Cliff is on the same page w.r.t. how much speculation is necessary (and when) to make JS go fast. In particular, inserting speculative guards has the nice property of improving downstream information for dominated control flow paths. Dominated control flow paths are few and far between when the co…
I've been quite smitten with Destination-Driven Code Generation and its separate data and control destinations feeding through to the sub-trees letting everyone know what's expected to happen to the data they're computing and where to go next. Makes a super-simple CPS converter as destinations == continuations and I can feed the CPS IR straight into a Click-inspired optimizer to do the things. It's actually fairly close to the design from TFA just based around continuations and whatnot instead of a SSA IR.