-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
NIR: Nim intermediate representation #22777
Conversation
Lol, I cannot type "intermediate representation", better only use IR. |
If it opens the gateway for CPS support, then I'm on board |
Does web assembly factor into this at all? I'm sorry if this doesn't seem relevant, but it feels like web assembly runtimes will continue to ramp up in popular use until they rival the deployment level of Java. (And I know that web assembly is not really like assembly). |
The IR can be translated to web assembly, yes. I have no plans to do that but in general writing a backend against the IR should be easier than previously. |
Is it going to help with incremental compilation? |
It was designed with IC in mind but IC also needs more frontend patches or a new frontend altogether. First I replace the backend passes, then later (which is really much later) the frontend. In the end not much of the old compiler remains and we have IC. |
This can allow for a better Nimsuggest ? 🤔 |
No, nimsuggest is frontend business, this here is for the backend. |
How is this going to behave with multiple files, will it combine everything into one large list of instructions or is there intended to be some sort of import construct? |
Just my opinion, but if it moves Nim from c-backend - it is a bad from my POV, because intermediate C helps a lot pretty often when you dig into perf (and want to match c-lang perf). Debug Ffi bindings and etc. c-backend is a huge plus of Nim |
The IR is easy to interpret and if you do that the data types between compiled and interpreted code are mostly compatible so things should become easier for nimscripter. Yes, the IR has the notion of an "import" from different modules. If you seek to interpret the code, you need to have the imported modules in memory. Loading an IR file into memory is cheap as it is already in a linear format, there is little to do. |
There are no plans to abandon C as compilation target, but instead of the AST the NIR is translated to C. |
Translation to llvm means that Nim goes away from c-backend. LLVM is also not positive trend in my opinion. |
@inv2004 and what this means:
It seems to me like the idea here is to allow for more supported backends rather than less. |
Pretty sure the "Easily translatable to LLVM" is not meant to replace the standard C / C++ backends. It's just mentioning that this should make work like |
@Vindaar all I wanted to say - that all the things like asm, wasm, llvm and etc are interesting to play with, but it is 3rd priority to have it, but I was afraid that c-backend have a chance to loose its 1st priority. (Everything with llvm does not have the advantage Nim has) Also, I do not know, but are there any perf-advantages nlvm gives at the moment? The same is about wasm - are there any visible benefits to have it directly or from llvm compared to have it from generated c-code? If the IR makes the primary c-backend easier from logical endpoint - perfect |
Further commits in follow-up PRs. |
Thanks for your hard work on this PR! Hint: mm: orc; opt: speed; options: -d:release |
Seems to break koch tools with |
Ref #22777 (comment) Co-authored-by: SirOlaf <>
Theoretical Benefits / Plans:
In very early stages of development.
Todo:
default(T)
builtin.