[HN Gopher] Libgccjit AOT Codegen for Rustc
___________________________________________________________________
Libgccjit AOT Codegen for Rustc
Author : varbhat
Score : 103 points
Date : 2021-07-06 11:22 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| specialist wrote:
| The qrintf preprocessor accelerates sprintf expressions.
| https://github.com/h2o/qrintf
|
| Noob question: Can libgccjit be used to do the same at runtime?
| rightbyte wrote:
| Yes. You can compile arbitrary code at runtime. You can
| "extract" a function generated with libgccjit as a function
| pointer and use it in your static code.
| chrisseaton wrote:
| And the great think about this, compared to static code, is
| you can compile runtime data into this code if you want. So
| instead of storing something like a configuration value in a
| global variable which you then have to read, you can store it
| in the code!
| dipdapdup wrote:
| libgccjit looks good. Is it still bound to the GPL license?
| adamdusty wrote:
| As far as I can tell, yes. There is a "GPL licensed" footer at
| the bottom of the libgccjit page[0].
|
| [0]: https://gcc.gnu.org/wiki/JIT
| est31 wrote:
| And as the FSF has stopped requiring copyright assignments,
| their hands are bound for the future. If it turns out that
| something like LGPL is better in the long term, there is no
| chance for a relicensing in the future.
| CUViper wrote:
| That change came from the GCC steering committee, not the
| FSF.
| tadfisher wrote:
| This mostly matters for code contributions, correct? Does
| dynamically linking to libgccjit.so trigger the GPL
| requirements for the linking code?
| cygx wrote:
| _Does dynamically linking to libgccjit.so trigger the GPL
| requirements for the linking code?_
|
| Yes, the GPL triggers if you distribute programs that
| merely link against a thusly licensed library - at least
| that's the intention.
|
| Full disclosure, there _are_ people who disagree with the
| FSF 's interpretation, arguing that merely linking to a
| library doesn't necessarily create a derivative work. I
| don't know if that has ever been tested in a court of
| law...
| kibwen wrote:
| This backend is now sufficiently mature that the Rust Compiler
| Team is discussing upstreaming it (just the Rust part, not
| libgccjit itself): https://github.com/rust-lang/compiler-
| team/issues/442
| qalmakka wrote:
| This is very cool, I'd like to see more projects using libgccjit
| because it's much, MUCH nicer than the usual approach of building
| your frontend alongside GCC. I think it's the first step towards
| a modular GCC, which is an absolute necessity for it to stay
| relevant in an LLVM-dominated world.
| rightbyte wrote:
| I find libgccjit also way more clear and easy to use than LLVM
| for code compilation and execution. There is not to many
| functions to keep track off. The 'goto' centric code generation
| is nice to wrap your head around.
___________________________________________________________________
(page generated 2021-07-06 23:02 UTC)