Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

C++ interop would make the whole issue moot since you wouldn't need most of the shim anymore: you'd only have to shim enough to interop with C++, then from that could call the LLVM API directly.


sort by: page size:

Why not just write the LLVM backend in C++? The C++ interface is actually pretty clean and really easy/trivial to use.

A question for the LLVM experts here:

In the past when I've looked at LLVM from a distance, the biggest stumbling block I found were that it's written in C++ , which isn't the language I'm using for my frontend.

How important is the C++ API in practice? Are the bindings for other languages usable? Is it possible to have my frontend emit LLVM IR in a text format, similarly to how you can feed assembly language source code to an asssembler? Or should one really just bite the bullet and use C++ to generate the IR? I noticed that the compiler in this tutorial has a frontend in Ocaml and a backend in C++, with the communication between them being done via protobufs.


That sounds really cool.

I did some searching to see people's experiences substituting other languages for C++ through LLVM, and didn't find much other than samples of translated calls.

Given that there would be a big benefit to this (not having to learn a new language, less manual memory management), are there good reasons this isn't way more common?


But isn't LLVM written in C++, too?

I would imagine that's the case. Either way, its nice to see llvm's c++ support coming along.

It's on the list of things that would be nice someday, but it will take a lot of time to get right, and it's not a high enough priority right now. There's a handful of other significant features that will come first, like ABI stability, Ceylon/Rust style ownership checking, first-class concurrency/atomics (async/await, etc.).

That said, Swift's C interop will work if you write an `extern "C"` interface to your C++. Obviously it's not ideal, but people have done projects like llvm-swift[0], with LLVM obviously being a C++ project.

[0]https://github.com/llvm-swift/LLVMSwift


Seems a huge pain relative to freestanding C++ to LLVM IR but more options in this space are welcome.

That counts. LLVM. Better than C++.

How about LLVM C & C++ ?

LLVM should be ported to C to be future proofed. Anything other than C++ at the very least.

I wonder if this would have been easier to accomplish with LLVM given that gcc's api is so notorious to deal with?

Seems to me these are orthogonal concerns, LLVM is in C++ but the question I answered was about using LLVM versus implementing a custom toolchain, not implementing a custom toolchain in C++ versus some other language.

I know about LLVM, but MLIR? Is the same?

And for the look of it, look like is not something that is viable to do without using C++?


I would love to have a way to bootstrap LLVM. This looks promising but I'm guessing a C++ frontend is much more challenging than writing this backend.

gcc used to be the missing link, but they switched to C++ and now you can't bootstrap it with something like tcc.


That's an especially interesting possibility since LLVM now has IR support for C++ coroutines.

LLVM isn't really a JIT, and I've never heard of people using it as one for C++. (Also, those that tried to use it as a JIT had lots of problems, like Unladen Swallow).

Wouldn't that be even easier if you used LLVM IR, as you'd then be able to write your runtime in any language that LLVM supports?

llvm has pretty good cross compiler support, So I don't know.

Feeling the pressure from LLVM? It's programmed almost entirely in C++.
next

Legal | privacy