nnx

JSIR: A High-Level IR for JavaScript

https://discourse.llvm.org/t/rfc-jsir-a-high-level-ir-for-javascript/90456

[RFC] JSIR: A High-Level IR for JavaScript

This RFC introduces JSIR, a high-level IR for JavaScript: JSIR preserves all information from the AST and supports high-fidelity round-trip between source ↔ AST ↔ JSIR; JSIR uses MLIR regions to represent control flow structures; JSIR supports dataflow analysis. JSIR is developed and deployed in production at Google for code analysis and transform use cases. JSIR is open source here: GitHub - google/jsir: Next-generation JavaScript analysis tooling · GitHub. Motivation Industry trend of bui...

LLVM Discussion Forums
Apr 8 at 12:59amWeb
Show threadsheepscreek1d ago

This is exciting stuff!

My interpretation:
If the JSIR project can successfully prove bi-directional source to MLIR transformation, it could lead to a new crop of source to source compilers across different languages (as long as they can be lowered to MLIR and back).

Imagine transmorphing Rust to Swift and back. Of course you’d still need to implement or shim any libraries used in the source language. This might help a little bit with C++ to Rust conversions - as more optimizations and analysis would now be possible at the MLIR level. Though I won’t expect unsafe code to magically become safe without some manual intervention.

Show threadjcuenod1d ago

I came across this project in the last couple of days too. Being able to decompile from Hermes bytecode sounds awesome.

Here's the repo: https://github.com/google/jsir (it seems not everything is public).

Here's a presentation about it: https://www.youtube.com/watch?v=SY1ft5EXI3I (linked in from the repo)

GitHub - google/jsir: Next-generation JavaScript analysis tooling

Next-generation JavaScript analysis tooling. Contribute to google/jsir development by creating an account on GitHub.

GitHub
Show threadhajile1d ago

I want them to finish the official TC39 binary AST proposal. Nearly twice as fast to parse and a bit smaller than minified code makes it a pretty much universally useful proposal.

https://github.com/tc39/proposal-binary-ast

GitHub - tc39/proposal-binary-ast: Binary AST proposal for ECMAScript

Binary AST proposal for ECMAScript. Contribute to tc39/proposal-binary-ast development by creating an account on GitHub.

GitHub
Show threadcroes1d ago

IR = Intermediate Representation

https://en.wikipedia.org/wiki/Intermediate_representation

Intermediate representation - Wikipedia

Show threadtamimio1d ago
Thank you, half way through the article and I am thinking infrared.
Show threadpizlonator1d ago

> Industry trend of building high-level language-specific IRs

"Trend"?

This was always the best practice. It's not a "trend".

Show threadsjrd1d ago

It seems to me that there's a certain "blindness" between two compiler worlds.

Compiler engineers for mostly linear-memory languages tend to only think in terms of SSA, and assume it's the only reasonable way to perform optimizations. That transpires in this particular article: the only difference between an AST and what they call IR is that the latter is SSA-based. So it's like for them something that's not SSA is not a "serious" data structure in which you can perform optimizations, i.e., it can't be an IR.

On the other side, you actually have a bunch of languages, typically GC-based for some reason, whose compilers use expression-based structures. Either in the form of an AST or stack-based IR. These compilers don't lack any optimization opportunities compared to SSA-based ones. However it often happens that compiler authors for those (I am one of them) don't always realize all the optimization set that SSA compilers do, although they could very well be applied in their AST/stack-based IR as well.