William Woodruff via llvm-dev
2019-Mar-02 00:46 UTC
[llvm-dev] Support for out-of-tree backend passes?
Hi all, I've been doing some LLVM development recently, as was curious about the status/feasibility of allowing developers to write out-of-tree back-end passes (e.g. `MachineFunctionPass`es) in a matter similar to middle-end passes. 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. Could anybody more familiar with the back-end explain the technical hurdles/challenges involved in supporting out-of-tree back-end pass builds? Similarly, would work in the direction of supporting those builds be welcome? If so, it's something I'd like to look at. Best, William Woodruff william at yossarian.net [1]: https://github.com/samolisov/llvm-experiments/tree/master/llvm-backend-x86-machine-passes [2]: http://aviral.lab.asu.edu/llvm-writing-a-backend-pass/ [3]: (Thread) https://lists.llvm.org/pipermail/llvm-dev/2015-November/092030.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190301/669db5e5/attachment.sig>
Tim Northover via llvm-dev
2019-Mar-03 03:34 UTC
[llvm-dev] Support for out-of-tree backend passes?
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.
William Woodruff via llvm-dev
2019-Mar-03 04:15 UTC
[llvm-dev] Support for out-of-tree backend passes?
On Sat, Mar 02, 2019 at 07:34:50PM -0800, Tim Northover wrote:> 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).Yeah, that's a problem. My particular use case is mostly target-independent, so I hadn't thought about that. Well, I'll do some fiddling and see if anything sticks. Thanks for the response! William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190302/dfcaf14f/attachment.sig>