I find it shocking that 20 years after LLVM was created, gcc still hasn't moved towards modularization of codegen.
Isn't that very much intentional on the part of GCC?
Rust GCC backend: Why and how
11–20 of 138 posts
Re: Rust GCC backend: Why and how
#12I find it shocking that 20 years after LLVM was created, gcc still hasn't moved towards modularization of codegen.
GCC approach is on purpose, plus even if they wanted to change, who would take the effort to make existing C, C++, Objective-C, Objective-C++, Fortran, Modula-2, Algol 68, Ada, D, and Go frontends adopt the new architecture?
Even clang with all the LLVM modularization is going to take a couple of years to move from plain LLVM IR into MLIR dialect for C based languages, https://github.com/llvm/clangir
Re: Rust GCC backend: Why and how
#13Re: Rust GCC backend: Why and how
#14Earlier quoted context omitted.
Somewhat. Stallman claims to have tried to make it modular,[0] but also that he wants to avoid "misuse of [the] front ends".[1] The idea is that you should link the front and back ends, to prevent out-of-process GPL runarounds. But because of that, the mingling of the front and back ends ended up winning out over attempts to stay modular. [0]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... [1]: https…
Good lord Stallman is such a zealot and hypocrite. It's not open vs. closed it's mine vs. yours and he's openly declaring that he's nerfing software in order to prevent people from using it in a way he doesn't like. And refusing to talk about it in public because normal people hate that shit "misunderstanding" him. --- From the post: I let this drop back in March -- please forgive me. > Maybe that's the issue for GCC…
Re: Rust GCC backend: Why and how
#15Earlier quoted context omitted.
Isn't that very much intentional on the part of GCC?
Somewhat. Stallman claims to have tried to make it modular,[0] but also that he wants to avoid "misuse of [the] front ends".[1] The idea is that you should link the front and back ends, to prevent out-of-process GPL runarounds. But because of that, the mingling of the front and back ends ended up winning out over attempts to stay modular. [0]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... [1]: https…
Re: Rust GCC backend: Why and how
#16Is libgccjit not “a nice library to give access to its internals?”
Re: Rust GCC backend: Why and how
#17> On that note: GCC doesn't provide a nice library to give access to its internals (unlike LLVM). So we have to use libgccjit which, unlike the "jit" ("just in time", meaning compiling sub-parts of the code on the fly, only when needed for performance reasons and often used in script languages like Javascript) part in its name implies, can be used as "aot" ("ahead of time", meaning you compile everything at once, all…
Re: Rust GCC backend: Why and how
#18Earlier quoted context omitted.
Isn't that very much intentional on the part of GCC?
Not anymore. Modularization is somewhat tangential, but for awhile Stallman did actively oppose rearchitecting GCC to better support non-free plugins and front-ends. But Stallman lost that battle years ago. AFAIU, the current state of GCC is the result of intentional technical choices (certain kinds of decoupling not as beneficial as people might think--Rust has often been stymied by lack of features in LLVM, i.e. de…
Re: Rust GCC backend: Why and how
#19Re: Rust GCC backend: Why and how
#20I find it shocking that 20 years after LLVM was created, gcc still hasn't moved towards modularization of codegen.