|8 days ago||4 days ago|
|Apache License 2.0||GNU General Public License v3.0 or later|
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Compiler Optimization Learning Suggestions
2 projects | /r/Compilers | 4 Aug 2023
Secondly, I have learned about LLVM, and I have learned about the Inkwell library on Rust (It's a New Kind of Wrapper for Exposing LLVM (Safely)). Has anyone used this library before? Is this a good practice? Is it suitable for my compiler? Can I write some optimization passes of my own using this library?
How Rust transforms into Machine Code.
5 projects | /r/rust | 3 Jun 2023
inkwell is a great llvm binding for rust and it has an implementation of kaleidoscope
Need help improving API for crate relying on Inkwell (Self-referential struct alternative)
2 projects | /r/rust | 24 Jan 2023
I'm working on a compiler that uses the LLVM wrapper Inkwell for compilation. In order to compile something in inkwell, unless I'm missing something (which I very well might be), you need two structs:
Tools for creating a programming language in rust
8 projects | /r/rust | 15 Nov 2022
Compiler backends (If building JIT/machine compiled langauges) 1. cranelift 2. inkwell - safe rust wrapper around llvm
How good is LLVM in other languages other than C++? (In my case I'm interested in using Rust)
6 projects | /r/ProgrammingLanguages | 3 Jun 2022
I'm currently using the Inkwell bindings for Rust, which I've found actually pretty nice. In terms of generating LLVM IR, the C bindings (which is what Inkwell uses internally) can do anything you want them to (definitely not limited to trivial languages as someone else here said.) I'm even using the LLVM garbage collection infrastructure, with no problems (well, no problems in generating it; the LLVM GC infrastructure works pretty well but is sparsely documented, so actually writing a GC is fairly difficult, but it's doable). The C bindings are actually more stable than the C++ bindings (!), although not quite as stable as the textual IR format; but without the bindings you would have to write code to generate the IR yourself, the compiler would be slower as it must be emitted as text and then reparsed in a different process, and you would have less control over optimization.
Are there any repos of tutorials on writing a compiler in Rust?
2 projects | /r/rust | 15 May 2022
safe llvm bindings https://github.com/TheDan64/inkwell
LLVM Infrastructure and Rust
3 projects | dev.to | 23 Dec 2021
As we reviewed in this article LLVM IR has many use-cases and allows us to analyze and optimize source code through its passes. Knowing IR language itself will help us to write our passes and build projects around it for debugging, testing, optimizing. Currently, LLVM IR doesn't have Rust API. It's mainly used through the C++ library. However, some user-created repos are available on crates.io. There is a Rust binding to LLVM's C API - llvm-sys and two other, more Rusty APIs that are using LLVM: inkwell and llvm-ir. And finally, if you want to learn how to write a LLVM pass you should start here.
What sort of mature, open-source libraries do you feel Rust should have but currently lacks?
22 projects | /r/rust | 1 Nov 2021
The high level crate is called inkwell.
What's the best way to generate LLVM code in Rust?
2 projects | /r/learnrust | 24 Oct 2021
https://github.com/TheDan64/inkwell is about as high-level as it gets (from what I've seen). It's based on top of llvm-sys, which is thankfully kept up-to-date with the LLVM releases.
VERY Slow compile times (15s+) with llvm-sys as a dependency
5 projects | /r/rust | 17 Oct 2021
On a side note, there are good high level bindings to llvm-sys, inkwell
Potential of the Julia programming language for high energy physics computing
2 projects | news.ycombinator.com | 30 Nov 2023
> OTOH, the existence of an ISO standard with multiple implementations can benefit the portability and longevity of code.
This is true for ISO standards that actually standardize features. Fortran's standard, since F'90, has instead been inventing features, and doing so without prototyping in actual implementations. And without supplying standardized test suites to guide those implementations. The results, in actual practice, have been at best mixed. There are features that are "standard" but not at all portable, due to spotty and divergent implementations, and there are portable features that are not standard. Some features have been in the language for >=20 years without yet appearing in popular compilers.
So yes, standardization (ISO or otherwise) can be a good thing. But it hasn't really been so for Fortran. And I think things are getting worse; F'2023 has changes in it that actually silently change the behavior of existing standard-conforming code, which would have been viewed as an abomination in earlier days.
References: see the LLVM Flang documentation on extensions, non-standard features, &c. in https://github.com/llvm/llvm-project/blob/main/flang/docs/Ex... and a suite of various incompatible feature tests in https://github.com/klausler/fortran-wringer-tests .
Fortran 2023 has been published
9 projects | news.ycombinator.com | 22 Nov 2023
flang , it's part of the LLVM project.
C++ Specification vs Implementation
3 projects | /r/cpp_questions | 19 Nov 2023
Bring garbage collected programming languages efficiently to WebAssembly
16 projects | news.ycombinator.com | 3 Nov 2023
LLVM isn't a virtual machine, but WASM is.
That's obviously a common misconception given the name -- LLVM was meant to be a VM early in its life, but never was, and isn't now. It's clarified in the first sentence of a home page - https://llvm.org/
It's basically a bunch of C++ libraries that implements an IR that changes over time, which help you write compilers.
Curiously, I think a decade or more ago there was a project at Google targeting the same space as WASM which made this mistake. They thought LLVM was a virtual machine! That was PNaCl or something.
I guess it's a little like LuaJIT freezing Lua at Lua 5.1 -- Lua was never a standard, but for the purposes of re-implementation, a specific version of it can be frozen. (But there are obvious problems with that approach, namely that the re-implementers don't know about all the bugs they're also freezing in time.)
I have raised some eyebrows at the "compromises" of WASM, but the once thing that you can't doubt is that it is in fact a virtual machine !!!
I watched a talk on the WASM GC, and the creators were up front about the compromises (e.g. you will need runtime casts at first, with the measured overhead being reasonable), which gives me more confidence in it:
Glibc Dynamic Loader Hit by a Nasty Local Privilege Escalation Vulnerability
4 projects | news.ycombinator.com | 3 Oct 2023
The fact that they haven't rewritten glibc's string parsing wouldn't make their criticism wrong.
If all of glibc had been written in assembly for every single target triplet, one wouldn't be wrong to point out that there was no benefit to doing that instead of writing it in C, and that it probably took more work and was more error-prone, even if they weren't willing to help port said code to C.
Just the same, they could have written this in C++.
Much of LLVM's libc is written in C++ with exposed C bindings (or all, I haven't checked 100%). For example, their libc stdio implementation is completely in C++.
You could say the same thing about Rust and Relibc, but it seems much less likely that a C project would incorporate Rust than that it would incorporate C++.
Fiber in C++: Understanding the Basics
8 projects | news.ycombinator.com | 24 Sep 2023
C++ ABI has some per-thread globals: the number that is returned from std::uncaught_exceptions(), and the chain of currently caught exceptions. For example in llvm this is available with a cxa_get_globals call:
These need to be saved/restored when switching fibers, otherwise fiber switches from catch clauses (and destructors!) are unsafe, throw without argument may rethrow incorrect exception, code that commits/rollbacks based on uncaught exceptions counter will not work correctly, etc.
One example I know where this save/restore is implemented is the userver framework, but it seems to be unexpectedly rare in fiber implementations last time I looked.
Changing the Rules of Rust
2 projects | news.ycombinator.com | 17 Sep 2023
I think you're correct that it's a big problem that the serious compilers don't actually have coherent internal behaviour, but I think that's a distinct problem which has been masked by the provenance problem in C and thus C++. It meant that real bugs in their software can be argued as "Works as intended" pointing to DR260 rather than anybody needing to fix the compiler.
For LLVM the effect of Rust has been to drag some of these issues into the sunlight, as it did for aliasing problems previously. https://github.com/llvm/llvm-project/issues/45725
Once the GCC work is closer to finished, I expect we'll see the same there.
I disagree that you need to solve the C problem first to solve the compiler problem, and I think it was misguided to start there. You seem to have focused on the fact that exposure is even an option in Aria's implementation, but let me quote: "The goal of the Strict Provenance experiment is to determine whether it is possible to use Rust without expose_addr and from_exposed_addr". Setting PNVI-ae-udi as "the" provenance rule is your end goal for C, but there's a reason it's called the "Strict Provenance" experiment in Rust, the goal is something like what you call PNVI-plain.
APIs like map are key to that goal, Rust has them and N3005 does not.
So like I said, rather than just being a "translation" I think the most that can be said is you've got the same problem albeit in a very different context, and your solutions are related in the way we'd expect when competent people attack similar problems.
Using Uninitialized Memory for Fun and Profit (2008)
3 projects | news.ycombinator.com | 3 Sep 2023
> 1. it's insane. nobody would write such an optimization because there's no possible performance gain, and it changes program behavior
LLVM explicitly has an 'undef' constant value which facilitates this optimization. https://llvm.org/docs/LangRef.html#undefined-values
FWIW, the most important reason compilers do this is to decrease compile time. The compiler notices that some code is insane because it's down an unreachable path, and it deletes the code now instead of waiting to prove the path is unreachable. The later optimizations tend to be slower and scale badly with more code in the function, so deleting it earlier will speed up the compile.
> 2. malloc is just a function, it's not treated in any special way
The compiler is full of optimizations that treat malloc and other functions specially. This file implements an analysis, but the results of the analysis is used by transformations. https://github.com/llvm/llvm-project/blob/main/llvm/lib/Anal...
> 3. there's no guarentee this malloc is a per-spec malloc, it can be a user-defined function for which this is perfectly valid
Yep, there's a flag for that mode, `-ffreestanding` which corresponds to freestanding mode in the C89 standard, chapter 2 section 220.127.116.11.3 projects | news.ycombinator.com | 3 Sep 2023
to address the points in order:
1. a specific optimisation pass won't do this, but the combination of several passes written with other intentions can
2 & 3. the C runtime a compiler links with is known to the compiler/linker, and it _does_ usually treat intrinsics like malloc specially
A quick google reveals https://github.com/llvm/llvm-project/issues/52930, LLVM recognising uninitialised memory as 'undef', and needing to treat it as poisoned (IIRC propogation of undef can cause things like separate uses of the variable to not even unify to a single value)
4 projects | news.ycombinator.com | 28 Aug 2023
Unfortunately, the necessary restrictions on data accesses to enable parallel execution are not required to hold true in the body of a DO CONCURRENT loop by its botched specification, and neither can they be verified at compilation time. And the committee has known about these problems for nearly six years and has refused to fix them; Fortran 2023 still has them and the topic is not going to be brought up again for Fortran 2028.
So it is possible for a conforming program to be non-parallelizable, due to holes in the default data localization rules, despite the name of the construct and the obvious intent of the long list of restrictions imposed on code in the construct.
I summarized the two specific problems in https://github.com/llvm/llvm-project/blob/main/flang/docs/Do....
What are some alternatives?
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
rust-langdev - Language development libraries for Rust
llvm-ir - LLVM IR in natural Rust data structures
Lark - Lark is a parsing toolkit for Python, built with a focus on ergonomics, performance and modularity.
SDL - Simple Directmedia Layer
cosmopolitan - build-once run-anywhere c library
langs-in-rust - A list of programming languages implemented in Rust, for inspiration.
STL - MSVC's implementation of the C++ Standard Library.
Graal - GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
skia - Skia is a complete 2D graphic library for drawing Text, Geometries, and Images.