[llvm-dev] Support for out-of-tree backend passes?

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Sat Mar 2 19:34:50 PST 2019


On Fri, 1 Mar 2019 at 16:46, William Woodruff via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> From the limited resources I can find online[1][2][3], LLVM currently
> doesn't support building back-end passes outside of the source tree.

I think that's right.

> Could anybody more familiar with the back-end explain the technical
> hurdles/challenges involved in supporting out-of-tree back-end
> pass builds?

One issue is that backend passes are usually pretty order-critical.
In-tree ones have a series of hooks where the target can add its
passes (e.g. addPreSched2, ...). As long as you solve that (maybe via
a new method on MachineFunctionPass?), I imagine the C++ effort in
LLVM would mostly be copy/pasting from the IR-level infrastructure
into the relevant parts of lib/CodeGen/TargetPassConfig.cpp and llc
(and Clang?).

The biggest difference and problem I see would be building the thing,
since the target's headers are going to be needed, but they're
private. That means they're not shipped with LLVM so you'd need the
source (and an active build directory for the TableGenerated files,
lib/Target/XYZ/XYZGen*.inc), which might make the whole project moot
(depending on your reasons for doing it).

It would also probably add a bunch of CMake magic to the project,
which is getting uglier the more I think about it (mixing build &
source content? "make super-install"?).

> Similarly, would work in the direction of supporting those
> builds be welcome? If so, it's something I'd like to look at.

I'm afraid I'm not sure there, and it'd be good to get more input.

My initial thought is that it sounds pretty invasive for a feature
with limited applicability, but I'm just one cranky individual
imagining proprietary obfuscation passes and other things I have no
business kibbitzing about.

Cheers.

Tim.


More information about the llvm-dev mailing list