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>
Nemanja Ivanovic via llvm-dev
2019-Mar-04 22:26 UTC
[llvm-dev] Support for out-of-tree backend passes?
I think another source of difficulty is specifying what representation the pass runs on. Don't forget that the back end lowers LLVM IR to SDAG, then the SDAG is selected, converted into SSA MIR, then RA and rewriting happens to take it out of SSA and finally it lowers to the MC layer. It would be ambiguous to invoke llc -my-pass unless we are restricting the passes to IR->IR ones, restricting it to pre-codegenprep and generally imposing the same requirements on the passes as exist in the middle end. On Sat., Mar. 2, 2019, 11:15 p.m. William Woodruff via llvm-dev, < llvm-dev at lists.llvm.org> wrote:> 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190304/5b510275/attachment-0001.html>
William Woodruff via llvm-dev
2019-Mar-05 02:01 UTC
[llvm-dev] Support for out-of-tree backend passes?
On Mon, Mar 04, 2019 at 05:26:16PM -0500, Nemanja Ivanovic wrote:> Don't forget that the back end lowers LLVM IR to > SDAG, then the SDAG is selected, converted into SSA MIR, then RA and > rewriting happens to take it out of SSA and finally it lowers to the MC > layer. It would be ambiguous to invoke llc -my-pass unless we are > restricting the passes to IR->IR ones, restricting it to > pre-codegenprep and generally imposing the same requirements on the > passes as exist in the middle end.Excellent points. My use case does indeed involve just IR->IR, but there's not much point in exposing the back-end if more diverse cases don't benefit from it. In the mean time, I've been successfully implementing what I want with a combination of a middle-end pass for metadata and an in-tree back-end pass for analysis. Thanks to all for answering my questions! 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/20190304/c416a651/attachment.sig>