Hacker News new | past | comments | ask | show | jobs | submit login

Wait, so has it stopped breaking? Because their breakage essentially killed the LLVM-based JIT compiler project for GNU Octave. Someone wrote it based on the C++ "API" and we spent time trying to keep up with it and then we gave up. Nobody really understood it well enough to rewrite it for the C API or knew if it was even possible, so we abandoned it.



The changes in the LLVM JIT were definitely a disappointment. IIRC it used to be a lot more lightweight the API was simpler to use.

But in hindsight it's hard to argue that the LLVM devs shouldn't have messed with it. Before you couldn't get symbolized stacktraces or use C++ exceptions. LLVM's primary goal has always been to produce the best code, and not necessarily try to be the fastest at doing it [1].

In the 3.x days, it was a fast evolving project. I remember projects I managed that used LLVM would no longer compile between releases because e.g. they would rename a header file.

"Just to rename a header file??" one might say; it's a subjective question whether this philosophy hurt or helped the project in the end. It might take years until that answer is forthcoming.

I'm sorry to hear about what happened with GNU Octave. Maybe after LLVM proves to stabilize someone new will write up the code :)

[1] Tangentially related: https://bellard.org/tcc/ Compiler Time(s) lines/second MBytes/second TinyCC 0.9.22 2.27 859000 29.6 GCC 3.2 -O0 20.0 98000 3.4


> But in hindsight it's hard to argue that the LLVM devs shouldn't have messed with it.

Not that hard, software stability is a very desirable property:

http://stevelosh.com/blog/2012/04/volatile-software/


The LLVM C Api is even worse. First it is tied to the 3x changing C++ Api, and it's incomplete. You can only do symbol search via C++.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: