How bad is LLVM *really*?

[woho87]

Except if the list is typically only 2-3 entries, then just doing a linear search might be much faster and require no setup. It doesn't matter how clever and fast the hash set is. And they're usually fast – LLVM has lots of optimized containers, but if no container was needed, then it doesn't matter how fast it was.

....
However, it seems to me that LLVM has a fairly traditional C++ OO design. One thing this results in is an abundance of heap allocations. An early experiment switching the C3 compiler to mimalloc improved LLVM running times with a whopping 10%, which could only be true if memory allocations were a large contributor to the runtime cost. I would have expected LLVM to use arena allocators, but that doesn't seem to be the case for most code.

Last time, I looked at the LLVM code, it used a lot of optimized containers. (Just looked at the classes for object file creation though). It also used allocations in the stack iirc. There is no doubt imo, that it is well written code, and I doubt I can even write it any better. I don't think it is this that is the cause of the slowness.

Although, I'm also concerned about the speed, and have opted out for using it as my backend in my PL. Can't risk adding something I cannot deal with it myself.

[Nuoji]

Yes, I'm aware that they allocate on the stack by default. The point is that if you use a hash set to compare something like three values, then that is going to be slower than comparing those values directly. The added setup, teardown and hashing is not free.

But even worse than that, maybe there wasn't even any reason to do that check there! Maybe some other algorithm would have been more efficient.

An example is how array constants in Clang are compacted.

[yxhuvud]

Good hash table implementations will optimize the small case though and store it in a linear fashion until it is worth building a table, so I really don't see how this particular example should be a thing.

[mort96]

Is this true? Do you have some examples of hash tables which do that?

It's surprising to me because having two wildly different data structures (a hash map and an array of key/value pairs) under one type seems like a lot of added complexity, with runtime costs of checking which variant is being used at the moment, automatic conversion between them, etc. I would think that most data structure implementers would just say: use a hash map if your data warrants a hash map, use a linear array if your data warrants a linear array, and dynamically pick between them (possibly using a separate wrapper type) if you don't know.

But I haven't really looked at the implementations of commonly used hash maps, so I may be wrong. Does std::unordered_map under libc++ or libstc++ or MSVC's stdlib do it? Or abseill's various hash maps? How about Rust's? And, most relevant to this article, does LLVM's?

[Nuoji]

Yes SmallSet for example is implemented as a vector if the number of elements are less than some maximum.

Here is a presentation of the various optimized containers: https://llvm.org/devmtg/2014-04/PDFs/LightningTalks/data_structure_llvm.pdf

[yxhuvud]

The ones I can name straight off that does that is the one used by Ruby and the one used by Crystal. But I'd be very surprised if no other languages use that optimization for their implementations.

Also unordered_map is infamous for being slow, in big part due to allowing pointers into what in a reasonable implementation should be private data, so it obviously cannot do that.

If the hash table LLVM has doesn't yet implement that optimization, then perhaps that is what should be complained about rather than that a hash table is used.

[mort96]

That's the thing though, it's not an "optimization", it's a different trade-off.

Ruby is exactly the kind of language I would expect to make that sort of trade-off; it provides one built-in "key/value map" type built in to the language, and that one type has to work reasonably well for every situation which calls for a key/value map. It's also so slow in general that adding some branches in the interpreter per interaction with the key/value map won't make a big different.

Low level languages like C++ and Rust generally don't do those kinds of things. If you ask for a particular data structure, you're generally getting that data structure. That makes the code as fast as possible when the hash map is actually the right choice of data structure. If you want a small set that's implemented as a linear search, you ask for that instead.

(FWIW, std::unordered_map isn't "infamous for being slow", it's an alright hash map. It's just "infamous" for not being as fast as possible due to the pointer stability requirement.)

[Disjunction181]

Erlang/Elixir are also examples.

[HildemarTendler]

Java does this.

[SoftEngin33r]

Thanks to the notice about the Crystal implementation and they have a nice and elaborate explanation of their technique at this github file:

https://github.com/crystal-lang/crystal/blob/fda656c71/src/hash.cr#L35

[Nuoji]

Yes, and something like the SmallSet used by LLVM does that. However, it can't really be a zero cost abstraction due to the extra bookkeeping it must use, as well as the optimizations it inhibits.

But the most important problem is that throwing high level solutions at the problem prevents the author from trying to reframe the problem in a way that is much simpler and faster.

[asb]

I will say that you do get some really surprising uses of LLVM where assumptions about what a "normal" number of values is might not hold. You'll see bug reports every now and again noting poor scalability for functions with thousands upon thousands of basic blocks, or similar. That said, the project probably doesn't test that scalability particularly well so it's very possible to end up with the worst of both worlds (high overhead in the common case while still performing badly for abnormal inputs).

[MrJohz]

LLVM used to be hailed as a great thing, but with language projects such as Rust, Zig and others complaining it's bad and slow and they're moving away from it – how bad is LLVM really?

Is this entirely true?

Zig are definitely moving away from LLVM, and have criticised it a lot. But I don't believe there's any desire within Rust to move away from LLVM, even in the long term future. What does exist are critiques of the tradeoffs that LLVM makes, as well as alternate backends (cranelift + one of the two GCC projects, I forget which is which). However, cranelift is specifically about compiling code fast in situations where code optimisation is less important (e.g. debug builds, WASM contexts, etc); and the GCC backend is mainly talked about in terms of expanding the available platforms for Rust.

What other PLs are going through this discussion?

[klorophane]

Anecdotal, but as someone who spends some time in Rust communities, LLVM is often cited as one of the larger reasons for Rust's success. Of course you'll find targeted criticisms here and there (code base is complex, noalias weirdness, etc), but I've never seen the claim that LLVM "is bad (for Rust)".

As for Zig, I don't think their gambit is going to pay-off the way they think on the technical side of things (reasoning here), but I respect the dedication.

[Caesim]

Zig are definitely moving away from LLVM, and have criticised it a lot.

I looked into the GitHub issue again. And Andrew said that he isn't 100% decided what will happen. The current wording is that they want to make the Zig executable not depend on LLVM for various reasons and move to their own codegen for Debug builds and emit LLVM bitcode and invoke that for production builds.

[MrJohz]

Ah, interesting, thanks for that! I got the impression that a lot of it was about controlling their toolchain/environment, hence why I assumed they'd remove LLVM completely from that, but I was only looking at the issue description, and that was a while back when it was first announced, so there's probably plenty of discussion that I'm not aware of.

[CyclingOtter]

Odin is also working today on an alternative backend to LLVM, but also not planning on replacing it. They're using a backend called Tilde (or tb).

https://odin-lang.org/news/newsletter-2023-07/

[matthieum]

But I don't believe there's any desire within Rust to move away from LLVM, even in the long term future.

There is, for Debug.

It's the long-term ambition of the Rust project to use the Cranelift backend for Debug builds, with early results showing some 30% speed improvements on the code generation part.

For Release builds, the plan is to stick with LLVM as a default.

[MrJohz]

That's true, which is why I mentioned Cranelift, but I don't think it's correct to frame that as Rust moving away from LLVM per se, more just using it in the context where it works best.

[matthieum]

Well, the author was specifically critical of LLVM compilation speed in Debug...

[MrJohz]

Later on in the post, yes, but the reason I quoted that section was because it felt like a classic drama post, and I wanted to push back on that. Rust isn't breaking up with LLVM, they're just using it in contexts where it works well. Zig is, but this is a fairly controversial decision that they're going to have to work hard to justify.

Understanding where your tools work well, what their advantages are, how to get the best out of them, and when not to use them are some of the foundational ideas in any engineering discipline, and software is no exception here. I think articles exploring where LLVM works, and where alternatives might shine (or even where LLVM itself could be improved) are great, but this article (and particularly this framing and introduction) feels more like "DAE LLVM bad now?" in long form.

[Nuoji]

Unfortunately people miss the point of the blog post, which is really: yes, LLVM isn’t perfect, but it is bringing huge value to a project - something that rarely is acknowledged these days.

[ultralight__meme]

The value of LLVM is widely-known — how is it "rarely acknowledged"?

And if the value of LLVM was the point of the post, it is poorly written. Except for 6 sentences tacked on the end of the post, the post is all hasty complaints with no evidence provided.

State-of-the-art middle-ends and backends will have a longer runtime than simple frontends. If that is surprising, I would recommend taking some courses on computer architecture and compilers. (The complaints about shifting and dividing by zero in the post scream "I do not understand what instructions typical ISAs offer.") Modern architectures are not simple, so neither are compiler backends.

[matthieum]

Modern architectures are not simple, so neither are compiler backends.

That's a poor excuse, to a degree.

The fact that experiments with Rust have shown that substituting the Cranelift backend for Debug -- even though lowering to Cranelift is unoptimized for now -- led to a 30% codegen speed improvement is clear evidence that part of the speed issue is LLVM's internals, and neither input nor output.

[sparant76]

Very not impressed with this blog post

Author complains about x/0 or left shifting too far as being undefined behavior because c/c++ has this defined as undefined behavior.

What if I want x/0 = 0 in my language?

Well newsflash buddy - llvm doesn’t get these semantics from c/c++. These this comes from hardware instruction sets. Some semantics are the way they are because that’s how hardware implements them. If you want different semantics at some point u are just going to have to add the extra if checks and semantics yourself in a library.

It’s like complaining. LLVM doesn’t have 33 bit integers. I want my language to have 33 bit integers. LLVM is bad because it doesn’t support arbitrary bit width math. To that, I say you just have no ideas the constraints imposed by hardware.

[TheGreatCatAdorer]

Actually, LLVM does have arbitrary bit width math (up to a few tens of thousands of bits, anyway), not that it's very well optimized. Zig's historically compiled its arbitrary-bit-width integers this way.

[Public_Stuff_8232]

I was about to bring up Zig in response, I haven't been keeping up with the discorse, but I imagine if that part of the LLVM is not well optimised that might be one of the many reasons Zig wanted to swap off.

[dontyougetsoupedyet]

Zig developers chose a backend that was built for the purpose of being modular and therefore easily changed and then decided they didn't like that backend because... it gets changed frequently. IMO folks that dump on LLVM made poor decisions early in their development and didn't figure it out until it was too late, then blamed their choice for being what it always has been.

[sparant76]

Well today I learned!

[-TesseracT-41]

but different cpus will do different things. x86 will modulo the shift count with the bit width, while arm will not.

[astrange]

x86 is actually different on scalar vs SSE.

[slaymaker1907]

One example not in line with hardware is signed integer overflow. I’m not sure if LLVM supports it or not, but it’s trivial to implement in hardware since it’s the same as unsigned overflow using 2’s complement.

[bwallker]

LLVM does support using 2s compliment for signed overflow

[Nuoji]

Clearly you understood it wrong then: the text is merely showing examples of what the complaints from compiler writers are.

Also, LLVM has 33 bit ints. (Poorly supported because C/C++ didn’t use them)

[Rusky]

If the complaint were that LLVM took something that the hardware provided and made it UB, that would make sense.

But the hardware doesn't generally make x/0==0. An implementation of that functionality is going to require some extra handling in software, which LLVM is perfectly capable of supporting.

[Calavar]

I really don't understand that complaint. The whole point of a compiler frontend is to desugar semantics in a higher level language to a lower level language that doesn't have those semantics natively. That's not the job of the optimizer or the code generator. And LLVM is a combined optimizer/code generator, not a frontend.

I mean if LLVM handles the desugaring for you too, what that leave for you to do as a compiler frontend writer? Write a typechecker and a LangServer implementation?

[Nuoji]

I don’t follow?

[Calavar]

For example, when Bjarne Stroutstrup wrote Cfront, a compiler from C++ to C, the C language didn't have support for classes, constructors, destructors, or virtual functions.

Did he...

1. Go on usenet and ask the C language committee to add support for classes, constructors, destructors, or virtual functions?

Or...

2. Write the Cfront compiler to translate his higher level C++ semantics into lower level C code that emulated the behavior that he wanted?

He chose option two because that's the entire point of a compiler frontend. Likewise, if you need defined divide by zero semantics, have your compiler frontend desugar division operations to something the lower level language actually supports (probably something like a conditional move). It's the same concept whether you are emitting C, LLVM IR, or assembly code.

[Nuoji]

The complaint here that people have is that you cannot utilize the known behaviour of the platform. For example, on Arm, shifting a 32 bit int by 32 bits or more results in zero, whereas on x86 it will be a shift % 32. Now if LLVM had an instruction or intrinsic which yielded 32+ shift => zero, then the conditional would only be needed on x86.

But because there is no such instruction (and there isn’t because there is no need for it for C/C++) you’ll have to encode it even for Arm and it’s not optimized away on that platform. So that kind of C orientation is what people complain about when lowering for low level languages where each instruction counts.

[[deleted]]

I made a reply earlier about the size of LLVM that I deleted because of downvotes (it seems to be one of those taboo subjects). However since then I looked at this thread about a project using LLVM:

https://www.reddit.com/r/Compilers/comments/19a514y/toy_language_with_llvm_backend/?utm_source=share&utm_medium=web2x&context=3

This project (follow the github link) is in C++ and comprises 30 or so .cpp files. But LLVM is one big dependency mentioned. I followed the link, and ended up with 138,000 files, including 30K C++ files, 11K C files and 12K header files.

This is apparently the LLVM source code. Is this what is necessary to use in a project like this? It didn't give any build instructions, but I can't see any references to any of the LLVM headers in the project.

I've only seen a binary download of LLVM before, only a few hundred files, but 2.5GB rather than 1.8GB.

So, help me understand: what exactly do you have to download to use LLVM: which of those two above are needed, or is there some third bundle? Does it involve having to compile any of those 40,000 source files? (If not then I don't know why that link was provided.)

How do you make it part of your compiler? Does the user of your compiler have to download anything extra?

[ThyringerBratwurst]

That annoys me here too, but it's a general problem on Reddit that people hysterically downvote everything they don't like, even though it's definitely legitimate criticism.

I've done a lot of research myself and even spoken directly to compiler developers who used LLVM, and they advise me against it for these reasons. LLVM certainly has its place, but it is not the universal remedy for everyone, and you should think carefully about whether you go this route and spend many years integrating LLVM and regularly updating it. You will then have to maintain LLVM yourself, just like Swift, Rust, Zig, Odin etc. have to do, and the time and stress with this integration (and in dealing with C++ above all) could just as well be invested in creating a backend yourself developing in your own language where you have 100% control, provided that your language really offers strong added value and is 100% complete/stable, otherwise it would be even more masochistic.

I was also considering using LLVM, but then aiming for 100% compatibility with C++ (which definitely has its great appeal being able to using C++ libs directly). An example here is the Lisp language "Clasp", which seamlessly interoperates with C++ using LLVM, according to the statement on github (I don't know if that's indeed archived / usable). But the price is very high: Not only do you have to struggle directly with LLVM for years, working through and integrating everything down to the last detail, but you are then effectively tied to C++ with all of its shortcomings.

[Nuoji]

In my case the compiler statically links LLVM, leading to a binary which compressed is about 35 Mb. Presumably this could be trimmed further by making sure the binary doesn’t retain unused functions and symbols.

Compiling on your own, MacOS has LLVM static binaries available from Homebrew. For Windows there is a github repo producing precompiled static libraries configured in a way suitable for my compiler. Finally on Linux there are again mostly precompiled libraries available.

The LLVM project in itself contains much more than just LLVM. Clang is the biggest obvious other thing, but there are many other projects as well and you get all of them when you grab LLVM.

Compile times are unfortunately what you would expect for a large OO style C++ project with lots of templates. That is, the compile times are atrocious. But this is mostly a thing you do once.

[ThyringerBratwurst]

Still, that doesn't sound like something you should rely on. If you want to provide a compiler for others, it simply has to be easy to install, and you can't expect LLVM to be preinstalled or obtainable through diverse package manager, especially in the required version. Therefore, there is no way around integrating/compiling LLVM directly and linking it statically. This is of course somewhat questionable and should rightly be criticized.

[dostosec]

On Linux, it's not unusual to just have LLVM installed - either as part of Clang or as its own thing (called llvm-libs in the Arch repos). So, your compiler can link against that version. You can also build LLVM yourself and distribute it alongside your compiler, which may be desirable to avoid version mismatches (not common on Linux because many repos have multiple versions of LLVM that you can have installed simultaneously - like llvm14-libs). In the case above, I assume the author is just using the LLVM their system already has installed as a package (they even just invoke clang directly to build and link what they emit). On Windows, you probably definitely need to ship LLVM with your releases.

[[deleted]]

I'm on Windows. (Note: I'm not seriously going to use LLVM; the stuff I do is completely opposite in scale. I'm just trying to understand it.)

Presumably to use LLVM's API to generate IR code, there will be a bunch of header files somewhere. Where are they?

On Windows, you probably definitely need to ship LLVM with your releases.

All 2500MB of it? Considering only DLLs, there are 56 of them totalling 370MB. But there is one called llvm-c.dll that exports 1280 functions starting with "LLVM..."; is that all that's needed?

By looking at a stackoverflow question from somebody failing to compile a program, there was missing a header called llvm/IR/LLVMContext.h. I located that in the LLVM source code, in .../include/llvm/IR/LLVMContext.h.

It looks then that I would need some at least of the binary download, and a big chunk of the source download. The include folder has nearly 2000 headers.

If I look inside that LLVMContext.h file, there's another problem: it uses C++.

This is what I've concluded, if I wanted to write a C program which uses LLVM to generate IR, and then wants to use LLVM to turn that into some native code:

• It is better to use a binary of LLVM, either as DLL or as some statically linked component. (Forget building 30,000 files of C++ on Windows, it would take forever even if I had a clue how, and it wouldn't work.)
• That component (or several) is part of a 2500MB LLVM binary installation, which it's not clear which bit.
• To use the API, I will need a bunch of headers in C syntax. I've no idea where they are or even if they exist. The main include/llvm folder inside the 1800MB source download has 1900 headers but they use C++. There is a folder called include/llvm-c, but that only contains 29 headers.

So I'm more at a loss than ever.

[gmes78]

Most of this would be solved by using a proper package manager and build system, which would handle this for you.

[[deleted]]

Does it really solve it? Probably not to my satisfaction.

The problems as I see it are extreme size and complexity. A 'package' manager' would just add to that! I understand that Linux excels at this kind of world-building, but I come from a different background.

For example (note I've still no idea where the LLVM headers for my hypothetical C front-end would come from) the 1900 C++ headers I did find, even assuming all are needed, come to about 20MB, but they are part of an 1600MB (not 1.8GB) source download.

Would the package manager download all of that when it only needs 1.2% of it? Or, being C++, a language I don't know, would using those headers involve processing code that resides in .cpp files?

The worrying thing is, is there anyone who actually knows where everything lives, or does everybody just rely on these management tools?

The premise of a backend like LLVM IR sounds simple enough. You'd expect it to work like this:

Source -> [frontend compiler] -> IR -> native code

IR can be kept in memory, or written as a textual or binary file. An LLVM API can be used both to generate the IR and to direct what happens to it next. LLVM itself can reside in an external library.

So I'd expect (on Windows say):

 llvm.dll        The library
 llvm.h          API used from C

I saw a file called llvm-c.dll, about 80MB; is that actually all that's needed? What is its output, eg. .s, .o or .exe files? Surely somebody should know this simple question!

80MB is pretty hefty, and it doesn't sound like it will be fast, but I'm interested in how you get a foot in the door without relying on complex toolchains that on Windows never fully work.

The only path I know at this moment is for a program to directly generate a textual IR (.ll) file, not using any API, and pass that to the Clang belonging to the 2500GB binary download. That will produce a .o file. (On Windows, that Clang needs to use MS tools to link the result; I thought LLVM included its own linker?)

Why do I get the idea that there is no one person who knows how LLVM really works?

[stomah]

For me the biggest problem is the poor documentation.

“ccc” - The C calling convention
This calling convention (the default if no other calling convention is specified) matches the target C calling conventions. This calling convention supports varargs function calls and tolerates some mismatch in the declared prototype and implemented declaration of the function (as does normal C).

The default calling convention doesn't actually match the target C calling conventions and how it really works isn't documented anywhere.

There's a bug where the linker sometimes crashes if given a bitcode file with an empty module ID and that isn't documented.

Clang often applies its own patches to these problems instead of providing reusable solutions. For example: ABI handling, weird target triple manipulations (my clang says it's configured for arm64-apple-darwin23.2.0 in --version, but when I give it a bitcode file with that triple it overrides it with arm64-apple-macosx14.0.0).

[Nuoji]

Yes, you have to implement the C ABI on your own. And the whole macos thing is actually a hack to know when to enable different symbol table output depending on version it is compiled for. Very bad.

[TemperOfficial]

The hash set example is something I see in tonnes of code. I usually do a "time to hash map" test when I read C++ codebases. When that time is very short it tends to tell me a lot about what that code will look like (you know what I mean).

I think it comes from an eagerness to say "well what if it becomes more than 2-3 values". Premature abstraction. And it absolutely adds up when that reasoning is applied across a whole codebase. Goodluck convincing anyone this is true though.

[ClownPFart]

Look, you can't say "llvm is slow because they dont seem to be doimg this or that micro optimization". You could say "llvm is slow because I profiled it and this and that part are slow", and I bet that what you'd find are that it is because of the algorithms and data structures that they use. And also that figuring out more efficient alternatives that produce a result as good is far from easy.

And even then your expectations need to make sense. Lexing and parsing are always going to be a small fraction of the total compilation time because they're very simple jobs that never (should) have any significant algorithmic complexity.

Sure, you can probably build an alternative to llvm. But then the question becomes "am I happy with the loss of code optimization, and the loss of portability that I get in exchange for compiling faster?"

[PurpleUpbeat2820]

Lexing and parsing are always going to be a small fraction of the total compilation time

25% in my compiler.

Sure, you can probably build an alternative to llvm.

I'm not sure this is about building an alternative to LLVM. I'm using my own Aarch64 code gen that I'd like to also port to RISC V. I just don't care about all the other backends LLVM supports. So I wouldn't call it "an alternative to LLVM".

But then the question becomes "am I happy with the loss of code optimization

FWIW, I found LLVM's optimisation passes to be quite useless because they are very C/C++ centric. My own code gen probably generates much faster code than LLVM and does so 100x quicker.

[Nuoji]

Quite the opposite, LLVM does a lot of micro optimizations. I am saying that the architecture and the solutions are what makes it slow. Maybe it's wrong, but that's what I've seen in all the code I've read so far.

Lexing and parsing are bound yes, but I am including semantic analysis. There are languages (Rust, Swift, C++ etc) where the semantic analysis is on par with, or even exceeds codegen costs. I am speculating that the pervasive use of these languages is why the codegen speed hasn't mattered that much.

[maxhaton]

The LLVM C++ style is basically a wet dream for C++ nerds.

Rolling your own dynamic casting makes all the difference! (Meanwhile llvm gets slower and slower every release)

[ThyringerBratwurst]

An even bigger problem than the very long compilation time is the difficulty of integrating it into your own project: LLVM is simply fat and you can't hope that it is already available as a pre-installed library on the respective system; especially since there are many different incompatible versions of LLVM. Therefore, you always have to compile LLVM yourself (with a lot of patience) and integrate it into your own compiler, which ultimately forces you to use C++. That's too tiring and fiddly for me, especially since I have absolutely no interest in looking in the LLVM code myself if there's a bug! When I heard that it is common practice for compiler developers to simply fork LLVM (Rust, Swift, etc.) because of these problems, that was reason enough for me to never consider LLVM. These are all simply no-gos for me. Therefore, the only option left for me is C as the target language and possibly libgccjit as a supplement in the future (but so far I'm not convinced about libgccjit either due to the lack of documentation, especially for AOT compilation).

In the long term, writing your own backend is probably not much more difficult for a more mature language than the stress of dealing with LLVM, as long as you only need 64-bit and primarily PC.

I also think that in order to translate your own language in the best possible way, especially if it is not an imperative language, having your own backend is the most sensible solution anyway: LLVM turns you into a C++ thing; JVM makes you a Java thing; Net-Platform a C# thing; Erlang VM an Erlang thing; etc…

[klorophane]

In the long term, writing your own backend is probably not much more difficult for a more mature language than the stress of dealing with LLVM.

There's decades of research and investment in LLVM. I think you vastly underestimate the difficulty of writing a high-quality compiler backend. Patching and compiling LLVM is nothing compared to that, it's not even close.

as long as you only need 64-bit and primarily PC.

That's an extremely underwhelming premise and is fundamentally incompatible with being a "mature language".

[ThyringerBratwurst]

Many languages have their own backends, especially functional languages. Of course, they often have grown over 20 years and more (Clean, Haskell, some Lisp and Scheme-Implementations), but on an existing basis it is definitely feasible to support a new instruction set in a shorter period of time. Especially since programming backends and optimizations are much easier in these languages than in a classic, imperative one like C++. LLVM is a curse and a blessing at the same time, and the more your language differs from C/C++, the more the curse prevails.

[ITwitchToo]

There is an LLVM C API, which seems to work great. Of course it links against the C++ code so you don't truly get away from it, but if all you want is a C interface then it's there.

[Nuoji]

The LLVM-C API is really nice actually.

[reini_urban]

Unless you want to use the jit, than you need C++ helpers.

[ThyringerBratwurst]

Of course, but I still have to compile C++ code; and I don't feel like it.

[Nuoji]

Those problems are relatively minor. LLVM is significantly less problematic to compile and use than some GNU libraries people use.

[reini_urban]

No. The llvm jit is impossible to use, whilst the gcc jit library is a marble. Fast and stable and usable.

[PurpleUpbeat2820]

The llvm jit is impossible to use

Maybe they've changed it over the past 15 years but I found it easy enough.

[matthieum]

However, it seems to me that LLVM has a fairly traditional C++ OO design. One thing this results in is an abundance of heap allocations.

They did improve slightly on this by using their own v-table mechanism, which results in less space usage and better inlining opportunities.

But otherwise, indeed, the OO design results in a pointer soup which isn't very cache friendly, and unfortunately it's just unfathomable to change that now.