Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could LLV8 be rebased on upstream V8 changes? #16

Open
CrazyPython opened this issue Jun 26, 2020 · 3 comments
Open

Could LLV8 be rebased on upstream V8 changes? #16

CrazyPython opened this issue Jun 26, 2020 · 3 comments

Comments

@CrazyPython
Copy link

I see LLV8 has modified Crankshaft. Upstream, V8 has removed Crankshaft.

How feasible (how much time) would it be to rebase V8 on upstream changes? Does LLV8 depend on CrankShaft?

@CrazyPython
Copy link
Author

Furthermore, for a CPU-intensive JavaScript application, how much better could LLV8 do over TurboFan?

@vivanishin
Copy link
Member

vivanishin commented Jun 28, 2020

Hi, thank you for your interest in this project.

First of all, you should know that LLV8 was a research project, and it hasn't been updated in a long time. This would make comparisons difficult, because a) not all operations are supported in LLV8 and b) I am not sure if it even builds, because the build system used for upstream V8 (used to be GYP) has changed since then, and the old one might not be available anymore.

Still, it was fun to hack on, and some important work has been done (supporting safepoints, OSR, and whatnot), so the project is kept here as a reference.

LLV8 surely does depend on Crankshaft: it uses the Hydrogen representation as an input, and lowers that into LLVM IR. Hydrogen was part of Crankshaft, so I assume it is now gone. There also used to be a baseline JIT compiler (Full CodeGen) rather than an interpreter, so deoptimization support might also need revamping.

So I expect porting LLV8 to new V8 to be about as difficult as writing from scratch, except perhaps the old implementation would serve as a reference (interaction of the compiled code with the VM is probably done largely in the same way). I haven't had a close look into Ignition and Turbofan, so I can't offer any estimation on how much benefit could there be had from using LLVM in terms of throughput. And also there's a design decision to make for such a hypothetical project as to what IR to use as an input for translation into LLVM IR. There's the bytecode (probably a good choice), then there's the Turbofan's IR (soup of nodes?), and also there's an option of just writing another backend for Turbofan that would use LLVM for codegen. There are different trade-offs associated with each solution.

@CrazyPython
Copy link
Author

CrazyPython commented Jun 29, 2020

How much information is lost by the lowering of JavaScript to Hydrogen?

I understand that Turbofan has an SSA-like sea of nodes representation. I also understand that LLVM is an SSA.

Did LLV8 have IPC support?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants