I want to build a custom compiler using LLVM and need to create a backend for a new target architecture. The documentation I found explains how to add targets directly inside the LLVM source tree using the standard lib/Target/ directory structure. This approach integrates well with LLVM’s build system and tools like llc and llvm-config.
However, I’m wondering if there’s a way to develop this backend target externally, outside of the main LLVM source code. I’ve seen that optimization passes and analysis components can be built separately and then loaded into tools like opt at runtime.
Is there a similar plugin-style approach available for backend targets? I’d prefer to keep my custom target code separate from the main LLVM codebase to avoid having to manage all those extra source files in my version control system and development environment.
LLVM doesn’t support loading backend targets as external plugins like it does for optimization passes. The target registration system needs deep integration with LLVM’s core during compile time, which means runtime loading won’t work. I encountered this limitation while building a custom DSP target recently. Essentially, you’re left with the option to statically link target components into LLVM tools, which necessitates modifying the main source tree or maintaining a personal fork. A practical approach is to create a minimal LLVM fork that only includes your target files in lib/Target/YourTarget. This method allows you to keep your changes contained while maintaining compatibility with LLVM’s build system, simplifying tracking of upstream LLVM changes and reducing maintenance overhead.
this is interesting! i’ve been curious about this too but never tried it. have you checked the external project examples that come with LLVM? they might have hints about loading custom components. what architecture are you targeting? the complexity might determine if it’s worth doing externally or just forking LLVM directly.
Yeah, unfortunately you can’t load backend targets dynamically like passes. I’ve hit this same wall before - target registration happens way too early in LLVM’s startup process. Your best bet is probably a separate build that statically links your target but keeps it outside the main tree using CMake’s external project features.