Is this project ready for production use?

[michaeleisel]

It's unclear to me from the readme what stage this project is in, and as a potential user I'd like to know that before trying it on large legacy code bases. Can it safely be used for large-scale projects? Has it already been used successfully for any, and to what degree was it validated (e.g., "it successfully compiled SQLite and passed all of its unit tests")? How many behavior tests does it pass (see https://ziglang.org/devlog/2025/#2025-06-08 ), and do these give us a similar level of confidence as Zig seems to have in their x86 backend? Is there any difference in the level of maturity between the x86 and ARM backends?

[aengelke]

tl;dr: Do you want to use our LLVM back-end (TPDE-LLVM) or build a back-end for a custom IR? For the former: probably yes; for the latter: it's unclear.

Has it already been used successfully for any, and to what degree was it validated (e.g., "it successfully compiled SQLite and passed all of its unit tests")? How many behavior tests does it pass (see https://ziglang.org/devlog/2025/#2025-06-08 ), and do these give us a similar level of confidence as Zig seems to have in their x86 backend?

For the TPDE-LLVM back-end: We run the llvm-test-suite SingleSource and MultiSource tests (which include several applications, gcc-c-torture, and others) as part of our (internal) CI with -O0 and -O1 IR on x86-64 and AArch64. We can compile around 95% of the tests (compile failures are largely related to inline assembly, computed goto, and missing x86-64 long double support), from the programs that we can compile all execution tests pass. Additionally, we regularly compile most parts of the LLVM monorepo (including LLVM, Clang, MLIR, Flang, etc.) (O0/O1 IR), here we have a fallback rate of <1% and all tests pass. (Fallback = our back-end encounters unsupported constructs and falls back to the regular LLVM back-end.) The API should be fairly stable and generally usable.

For the TPDE core: most parts are exercised through the LLVM back-end. Some more parts are covered through the Cranelift, Umbra, and LingoDB (MLIR) back-ends (not in this repo); we're currently not aware of correctness bugs. The API is not very stable and I expect some (non-substantial) changes in the future.

Is there any difference in the level of maturity between the x86 and ARM backends?

No, both receive a similar degree of testing.

It's unclear to me from the readme what stage this project is in, and as a potential user I'd like to know that before trying it on large legacy code bases. Can it safely be used for large-scale projects?

This is primarily a research project, but we do care a lot about stability and correctness. We'd be very interested in experiences from other users and can probably also look into arising issues.

TPDE-LLVM should fairly stable. Using the TPDE core directly for a new back-end might be possible for production use cases, but API breaks are to be expected and, depending on the IR, some changes might be needed. In any case, we'd appreciate more details on your use case. :) (We like to "know" our users so that we can avoid inadvertant breakage, etc.)

(Needless to say: as per the license, the project is provided "as is" without warranties of any kind, etc.)

[michaeleisel]

Thanks, this is very helpful. So my use case is to speed up clang compilations for a very large closed-source C++ code base. So, I only need to use the LLVM backend and nothing else. In certain corners of the code base, it uses pretty much every C++ feature (gotos, long doubles, inline assembly, etc.). In cases where tpde doesn't support something, is it always always able to detect that and fall back to LLVM, thus ensuring correctness? And when it does fall back, does that mean it redoes the whole object file with LLVM's backend, or just the pieces that it doesn't actually support? Like if I have a 100,000 line preprocessed C++ file, I wouldn't want one obscure usage of inline assembly in it to cause the whole thing to fall back to the LLVM backend.

[aengelke]

In cases where tpde doesn't support something, is it always always able to detect that and fall back to LLVM, thus ensuring correctness?

Yes, our Clang patch will cause a fallback for the entire object file. (NB: gotos are unproblematic, only computed gotos are unsupported.)

I wouldn't want one obscure usage of inline assembly in it to cause the whole thing to fall back to the LLVM backend.

This is unfortunately not easy to fix. (Hypothetically, we could separate modules in supported/unsupported parts and compile these into two object files; then merge these through a relocatable link. This, however, is very brittle and will lead to subtle semantic differences, so I don't think this is a good way. If certain constructs frequently cause fallbacks, it's easier to just implement them.)

[michaeleisel]

Ok nice! This isn't necessarily the end of world, I'll have to look at what files are actually doing in practice - does the tool make it clear when it's using a fallback? If so, I could then measure what % of our code base can receive a speedup. And, I assume that the fallback case is basically as fast as normal compilation? Since whatever tpde has done up to that point is so fast compared to the LLVM backend, and the fallback is just using LLVM? We want to use our own pre-built versions of clang and related LLVM tools, so I think the flow will look like:

# (pseudo-flags, since I'm too lazy to look up the right invocations right now)
clang --only-emit-llvm-ir -o output.ir
tpde-llc output.ir -o output.o

In that case, maybe the best thing is to just have tpde-llc fail instead of using a fallback, meaning the last line becomes tdpe-llc output.ir -o output.o || llvm-backend-foo output.ir -o output.o. This would mean that tpde-llc doesn't need LLVM (at least for our needs), we can use our existing pre-built toolchain for the fallback, and we can measure how much we do/don't take the fallback. Also, is it possible to trace the reason for a fallback occurring, or to have a relatively complete list of all the things that make it fall back?

[michaeleisel]

Related to the above comment, how closely does the version of LLVM in my pre-built clang need to match tpde's for it to work? Is tpde compatible with IR produced with older versions of LLVM? What about newer ones?

[aengelke]

does the tool make it clear when it's using a fallback? [...] Also, is it possible to trace the reason for a fallback occurring

tpde-llc will exit with a non-zero exit code and report the reason to stdout like this:

[2025-07-13 18:02:37.278] [error] Failed to compile instruction   %2 = fptosi float %1 to i128
[2025-07-13 18:02:37.278] [error] Failed to compile block 0 (label %0)
[2025-07-13 18:02:37.278] [error] Failed to compile function main
Failed to compile

I assume that the fallback case is basically as fast as normal compilation?

Yes. Given that Clang tends to dominate compile times (for Clang+TPDE, TPDE is <2%), I'd expect the additional cost of the TPDE attempt to be very small.

Related to the above comment, how closely does the version of LLVM in my pre-built clang need to match tpde's for it to work?

LLVM bitcode is backwards-compatible but not forwards-compatible. E.g., a tpde-llc linked against LLVM 20 can compile bitcode produced by Clang 18, but not Clang 21.

For testing, we use the following simple wrapper (tpde-clang, set env var TPDE_LLC to the path to tpde-llc, call with tpde-clang /path/to/clang++ <args>, suitable for CMAKE_CXX_COMPILER_WRAPPER), you could adapt this to implement the fallback to llc if tpde-llc fails. Note, however, that serializing and parsing LLVM bitcode is expensive (parsing bitcode is 4-10x more expensive than the compilation with TPDE itself). Using the Clang patch (or, alternatively, integrating TPDE somehow through Clang's plugin infrastructure) will give larger improvements.

#!/bin/bash
set -euo pipefail
compile=
args=("$@")
n=${#args[@]}
for ((i=0; i<n; ++i)); do
    case ${args[i]} in
        -o) output=${args[i+1]}; unset args[i]; unset args[i+1]; ((++i));;
        -c) compile=1;;
        -emit-llvm) compile=0;;
    esac
done
if [ -z $compile ]; then
    "$@"
else
    "${args[@]}" -emit-llvm -o - | "$TPDE_LLC" -o "$output"
fi

[michaeleisel]

Thanks for that. With the strategy of piping the output to from clang ... -emit-llvm to tpde-llc, I see a roughly 100% increase in compile times, so as you suggested, that won't help. However, with TPDE-LLVM clang, I see a reduction of 10%. The primary issue in the files I've tested so far is inline assembly (I removed the inline assembly to benchmark it).

[michaeleisel]

FYI, Cranelift has said they have a nice solution for inline assembly: bytecodealliance/wasmtime#9923 (comment)

However, it's not too big a deal for me: moving the inline assembly from headers to helper functions in separate .cpp files, where the compilation time is not an issue, has solved the problem.

[michaeleisel]

By the way, are there any plans to try to get tpde-llc upstreamed to LLVM, e.g. so that upstream clang would use it for all -O0 builds? What blockers would there be to this, assuming that tpde supported everything that the LLVM backend did, such as inline assembly?

[aengelke]

By the way, are there any plans to try to get tpde-llc upstreamed to LLVM

No. This is probably not blocked by technical issues, but due to organizational downsides. Upstreaming would either require us to split TPDE and TPDE-LLVM (requires vendoring TPDE in LLVM, causes too much development friction) or to include TPDE entirely in the monorepo (requires all TPDE users to pull in the LLVM monorepo, huge dependency, also causes development friction). As I said earlier, I consider TPDE to be primarily a research project and the LLVM monorepo is not a good space for research. We don't deeply depend on LLVM internals, so there're no significant technical benefits either.

What I do plan is to adjust Clang so that TPDE-LLVM can be invoked as a Clang plug-in (clang -fplugin=/path/to/tpde.so ...) without requiring a patched Clang; that should be feasible to achieve in the time frame of Clang/LLVM 22.

[michaeleisel]

A plugin sounds great, that will definitely help with getting buy-in in my own organization to use this in more and more places.

As for the plan to not upstream, that makes sense! It could be helpful to explain the overall goals and direction of the project in the readme: the level of production-readiness (e.g. the testing that you've described here and whether or not large projects are using it successfully), the plan to not upstream it, the fact that it's a research project but one that cares about speed and correctness. It may at least save some time answering questions from software devs. Devs basically want to know in 30 seconds, "can I try this with some degree of confidence?". Some of this may be discussed in the white paper, but white papers scare us non-academics ;)

I plan to promote this project by sharing my own success with it, because the more widely used and accepted in the C++ community, the more it will be trusted within my own organization as a safe thing to use. I think this will be a very widely-used project in the C++ community in the future.

[oxcrow]

Do you want to use our LLVM back-end (TPDE-LLVM) or build a back-end for a custom IR? For the former: probably yes; for the latter: it's unclear.

If I may be allowed to add to this conversation, I would like to use TPDE to compile LLVM IR that I have emitted from a compiler I'm developing.

That is, My intention is to speedup development builds using TPDE (instead of using LLVM).

However for that to happen, I would request TPDE devs to either,

• Try to get TPDE officially integrated within LLVM toolchain, (This is probably the best solution), or
• Provide unofficial TPDE patched binary executables (llvm-as, llvm-opt, etc.) that we can use to compile, optimize, link LLVM IR.

Because patching LLVM and compiling it manually is prohibitive for most people, due to how much time and resources it consumes. If TPDE team could kindly share binary executables that we can download and use, it would also allow future users of my language to download your binaries and benefit from the compilation speedup.

Thanks

[aengelke]

I would like to use TPDE to compile LLVM IR that I have emitted from a compiler I'm developing.

In that case it's most advisable to just link against the TPDE-LLVM library and use the API. TPDE-LLVM works with an unpatched LLVM (e.g., as provided by Linux distributions). The provided patch is solely for the efficient integration into Clang/Flang, as they currently lack a suitable plugin API.

There're no plans to upstream TPDE into the LLVM monorepo (see above) and there're also no plans to distribute binaries.