4 ms·
Every JIT that starts out by generating code directly from expression trees or bytecode eventually grows an ad-hoc optimizer and IR. I think its probably better
by slavapestov 8y ago
Every JIT that starts out by generating code directly from expression trees or bytecode eventually grows an ad-hoc optimizer and IR. I think its probably better to avoid all the dead ends and lower directly to an SSA IR. You can then implement tried-and-true optimizations from compiler textbooks, and concerns such as "optimizing across expression boundaries" or "my expression tree is actually a DAG" are defined away completely.
- brrt 8y agoHi! Author here. Honest question, because I don't know all the facts: - Given that in this IR, every value has a single definition, and every use must reference that value, I'd argue that this is already SSA form. - In fact, the concept of 'variable' is mostly missing, there's only a repeated reference to the same value. I think that simplifies things a lot, but maybe too much. - Optimizing across expression boundaries is in fact very much the point, if we can keep the semantics the same. Thanks for your interest!
- comex 8y agoWell... one thing that's usually done as part of converting something to SSA form is computing the dominator tree. If you did that, you could relatively cheaply solve this: > But it also means that the property we're interested in - a value is computed before it is used in, in all possible code flow paths - isn't really expressible by the IR. ...since you could verify that the blocks a value is used in are dominated by the block it's computed in.