3 ms·

This is so ugly. > The next step is telling GCC configure that we are going to build GCC with tiny support. This will fail. Do not worry, this is expected. Ba

by aleden 9y ago

This is so ugly. > The next step is telling GCC configure that we are going to build GCC with tiny support. This will fail. Do not worry, this is expected. Back in the 2.9 - 3.8 LLVM days there was a lot of API breakage between releases. A lot of people I knew who worked with LLVM detested this, but would you rather deal with this kind of cruft?

jordigh 9y ago
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.
- aleden 9y ago
  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/ 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
  - jordigh 9y ago
    > 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/ http://stevelosh.com/blog/2012/04/volatile-software/
- rurban 9y ago
  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++.

by aleden 9y ago

jordigh 9y ago

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.

aleden 9y ago
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/ 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
- jordigh 9y ago
  > 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/ http://stevelosh.com/blog/2012/04/volatile-software/
rurban 9y ago
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++.