4 ms·
> From my very personal point of view, the TurboFan optimizing compiler at that time was probably the most beautiful version we ever had, and the only version (
by jules 10y ago
> From my very personal point of view, the TurboFan optimizing compiler at that time was probably the most beautiful version we ever had, and the only version (of a JavaScript compiler) where I could imagine that a “sea of nodes” approach might make sense (although it was already showing its weakness at that time).
What were the weaknesses of the Sea of Nodes? Backwards data flow analysis and control flow sensitive analysis being hard?
- qznc 10y agoI worked on a Sea of Nodes compiler [0] myself and "backwards data flow analysis and control flow sensitive analysis" has never been a problem. Changes to the CFG are hard because of the Phi nodes, which have to be adapted in lockstep with CFG changes. However, this is probably inherent to SSA form, but not sea of nodes. You want a good graph visualization instead of text-based output, because you should actually to see the "non-order of the sea". Text-output with an implicit order can hide issues. Personally, I believe sea of nodes is better then others, like SSA form is better than non-SSA. There is nothing which makes it inherently more powerful, but it feels more elegant. Unfortunately, there is no objective comparison and anecdotes are apples vs oranges. Similarly, how would you compare object-oriented with functional programming? [0] http://libfirm.org http://libfirm.org
- jules 10y agoLibFIRM's sea of nodes representation is a bit different in that nodes are tied to a basic block, if I understand it correctly. That would indeed make control flow sensitive analysis easy. Their sea of nodes representation does not have this property, so it is not immediately apparent under what control conditions a node may be executed. Their scheduler will place nodes in basic blocks at the end of the pipeline. I loved your paper about PBQP register allocation, by the way!