Live data from Hacker News

The acyclic e-graph: Cranelift's mid-end optimizer

cfallin.org

21–25 of 25 posts

Re: The acyclic e-graph: Cranelift's mid-end optimizer

#21
post #19
post #17

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 dummies phrasing is my own, and I stand by it - I simply find the CFG way of thinking much easier to reason about than the SoN way, and I find myself falling back into it no matter how hard I try to follow what I totally (abstractly) appreciate is a more mathematically beautiful dependency/anti-dependency graph - I think that's a limitation of my ability to maintain that concept in my mind and that other people can do it better than me. I find it far easier to reason on CFG terms most of the time, and to raise the CFG temporarily into some dependency representation for doing eliminations/hoisting/LICM, than I do maintaining that dependency representation across all phases and accurately reasoning in each of those about what concrete dependency I forgot about when writing the reduction (concrete recent example, I tried to make reading from holes segfault by unmapping the hole, to force potential holey field access to always first compare against the sentinel, but I was foiled by TF since the load had no dependency on the hole compare branch and could be hosted above it). Implying that this was simply "some people" insisting on only thinking one way without trying to think the SoN way, or that it was some sort of CFG prejudice, is the actual strawman here.

Re: The acyclic e-graph: Cranelift's mid-end optimizer

#24
post #6
post #4

> 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…

Thanks for the lengthy response.

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

#25
post #19
post #17

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…

> Control and effects are different things...

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.

Post reply on HN