[NewPM] Add C bindings for new pass manager

[supergrecko]

Summary

This patch contains the bare minimum to run the new Pass Manager from the LLVM-C APIs. It does not feature PGOOptions, PassPlugins or Debugify in its current state. Bugzilla: PR48499

[supergrecko]

Not quite sure how we want to register the StandardInstrumentations here... Right now it's not registering any PassInstrumentationCallbacks at all because I'm not too sure how we wanted to handle that either.

StandardInstrumentations::registerCallbacks takes the FunctionAnalysisManager which means we'd need to have the FunctionAnalysisManager instance at the time the StandardInstrumentation is registered. Not sure how to move forward here. Let me know what you think.

llvm/lib/Passes/PassBuilderBindings.cpp

64

I made the choice to dispose of the PassBuilder once you've run it over a module because we're setting up a whole bunch of things like AnalysisManagers (and thus changing the underlying PB) based on the Debug and VerifyEach parameters which could be different if the client was to call LLVMRunpassBuilder again. Let me know if you believe this is wrong.

[myhsu]

In D102136#2746728, @supergrecko wrote:

StandardInstrumentations::registerCallbacks takes the FunctionAnalysisManager which means we'd need to have the FunctionAnalysisManager instance at the time the StandardInstrumentation is registered. Not sure how to move forward here. Let me know what you think.

I think you can build PassBuilder with an uninitialized PassInstrumentationCallbacks object and retrieve it via PassBuilder::getPassInstrumentationCallbacks before populating it with StandardInstrumentation when FunctionAnalysisManager is available (getPassInstrumentationCallbacks is marked const but the returned pointer is not so I'm not complaining :-P. Plus, the comment for getPassInstrumentationCallbacks also hints this usage).

Also I'm wondering what about other methods in PassBuilder? For instance those "buildXXXPipeline" methods. Do you have any plan/roadmap for adding them? (I'm not saying you should add all of them in a single patch but just curious :-) Since I actually use those methods more often than parsePassPipeline)

llvm/lib/Passes/PassBuilderBindings.cpp

40

I feel this name is a little bit mis-leading since you're only calling parsePassPipeline here, which is not the only features provided by PassBuilder

[supergrecko]

I think you can build PassBuilder with an uninitialized PassInstrumentationCallbacks object and retrieve it via PassBuilder::getPassInstrumentationCallbacks before populating it with StandardInstrumentation when FunctionAnalysisManager is available (getPassInstrumentationCallbacks is marked const but the returned pointer is not so I'm not complaining :-P. Plus, the comment for getPassInstrumentationCallbacks also hints this usage).

That sounds like the solution I was looking for. Excellent, thank you!

Also I'm wondering what about other methods in PassBuilder? For instance those "buildXXXPipeline" methods. Do you have any plan/roadmap for adding them? (I'm not saying you should add all of them in a single patch but just curious :-) Since I actually use those methods more often than parsePassPipeline)

I believe the initial plan was to provide an interface to the parserPassPipeline bits of the PassBuilder so I haven't thought too much about it. That's definitely something we could do, in which case I think we could just return a ModulePassManager from the (currently named) LLVMRunPassBuilder function. Arthur and I discussed separating the PassBuilder and ModulePassManager APIs and this seems like a good reason to do that.

llvm/lib/Passes/PassBuilderBindings.cpp

40

Yeah, I'm sure there are better names than LLVMRunPassBuilder. I named it LLVMRunPassBuilder because it ends up running the PM, but a name like LLVMParsePassPipeline seems like a better fit. It would also make sense to name it something along those lines if we separate the ModulePassManager API out of this function.

[myhsu]

In D102136#2746835, @supergrecko wrote:

Also I'm wondering what about other methods in PassBuilder? For instance those "buildXXXPipeline" methods. Do you have any plan/roadmap for adding them? (I'm not saying you should add all of them in a single patch but just curious :-) Since I actually use those methods more often than parsePassPipeline)

I believe the initial plan was to provide an interface to the parserPassPipeline bits of the PassBuilder so I haven't thought too much about it. That's definitely something we could do, in which case I think we could just return a ModulePassManager from the (currently named) LLVMRunPassBuilder function. Arthur and I discussed separating the PassBuilder and ModulePassManager APIs and this seems like a good reason to do that.

Yeah separating them definitely sounds better

[aeubanks]

I'm very grateful there are tests, some of the other C bindings I've worked with never had any :)

In D102136#2748098, @myhsu wrote:

In D102136#2746835, @supergrecko wrote:

Also I'm wondering what about other methods in PassBuilder? For instance those "buildXXXPipeline" methods. Do you have any plan/roadmap for adding them? (I'm not saying you should add all of them in a single patch but just curious :-) Since I actually use those methods more often than parsePassPipeline)

I believe the initial plan was to provide an interface to the parserPassPipeline bits of the PassBuilder so I haven't thought too much about it. That's definitely something we could do, in which case I think we could just return a ModulePassManager from the (currently named) LLVMRunPassBuilder function. Arthur and I discussed separating the PassBuilder and ModulePassManager APIs and this seems like a good reason to do that.

Yeah separating them definitely sounds better

I still think keeping them together is a better idea.
For buildXXXPipeline methods, we can expose those via the pass parsing interface by adding them to PassRegistry.def.

The weird quirk of disposing the PassBuilder when it's passed to LLVMRunPassBuilder and the awkward naming of LLVMRunPassBuilder are easily resolved if we combine the two, since PassBuilder will be internal to that one function, and LLVMRunPasses seems nice

llvm/lib/Passes/PassBuilderBindings.cpp

70

these options can't be all set in one exposed interface, they each need separate functions (like PassManagerBuilder options)
if we add new options in the future, we can't just update a C function signature

[supergrecko]

In D102136#2748572, @aeubanks wrote:

The weird quirk of disposing the PassBuilder when it's passed to LLVMRunPassBuilder and the awkward naming of LLVMRunPassBuilder are easily resolved if we combine the two, since PassBuilder will be internal to that one function, and LLVMRunPasses seems nice

LLVMRunPasses would be nice and descriptive for its task. I'm not too sure I understood what you mean by "the quirk of disposing the PassBuilder (...)"; would it be preferable to have the client dispose it themselves? If the PassBuilder is re-usable after a run it would probably not make sense to get rid of it, but you know more about that than I do. Let me know what you think is the correct decision here.

llvm/lib/Passes/PassBuilderBindings.cpp

70

Good catch. I'll refactor that into LLVMPipelineTuningOptionsSetX functions.

[aeubanks]

In D102136#2749071, @supergrecko wrote:

In D102136#2748572, @aeubanks wrote:

The weird quirk of disposing the PassBuilder when it's passed to LLVMRunPassBuilder and the awkward naming of LLVMRunPassBuilder are easily resolved if we combine the two, since PassBuilder will be internal to that one function, and LLVMRunPasses seems nice

LLVMRunPasses would be nice and descriptive for its task. I'm not too sure I understood what you mean by "the quirk of disposing the PassBuilder (...)"; would it be preferable to have the client dispose it themselves? If the PassBuilder is re-usable after a run it would probably not make sense to get rid of it, but you know more about that than I do. Let me know what you think is the correct decision here.

It's weird that clients only sometimes manually dispose of the PassBuilder. For example, if a language with destructors were to wrap LLVMPassBuilderRef, there'd be weird logic in the destructor on when to call LLVMDisposePassBuilder. I'm not worried about supporting reusing a PassBuilder.
IMO we should only have the creation/setup of options (in this case PTO, maybe some other things like DebugLogging and TargetMachine), then pass those options and the pass pipeline string and the module to a LLVMRunPasses. This simplifies everything and we don't have to worry about any LLVMPassBuilderRefs since we won't be exposing it.

[supergrecko]

In D102136#2749370, @aeubanks wrote:

In D102136#2749071, @supergrecko wrote:

In D102136#2748572, @aeubanks wrote:

The weird quirk of disposing the PassBuilder when it's passed to LLVMRunPassBuilder and the awkward naming of LLVMRunPassBuilder are easily resolved if we combine the two, since PassBuilder will be internal to that one function, and LLVMRunPasses seems nice

LLVMRunPasses would be nice and descriptive for its task. I'm not too sure I understood what you mean by "the quirk of disposing the PassBuilder (...)"; would it be preferable to have the client dispose it themselves? If the PassBuilder is re-usable after a run it would probably not make sense to get rid of it, but you know more about that than I do. Let me know what you think is the correct decision here.

It's weird that clients only sometimes manually dispose of the PassBuilder. For example, if a language with destructors were to wrap LLVMPassBuilderRef, there'd be weird logic in the destructor on when to call LLVMDisposePassBuilder. I'm not worried about supporting reusing a PassBuilder.
IMO we should only have the creation/setup of options (in this case PTO, maybe some other things like DebugLogging and TargetMachine), then pass those options and the pass pipeline string and the module to a LLVMRunPasses. This simplifies everything and we don't have to worry about any LLVMPassBuilderRefs since we won't be exposing it.

Aha, gotcha. I'll make it so the PassBuilder is kept private to LLVMRunPasses, removing LLVMPassBuilderRef and friends. That should result in an API looking like this:

LLVMErrorRef LLVMRunPasses(LLVMTargetMachineRef TM,
                           LLVMPipelineTuningOptionsRef PTO, LLVMModuleRef M,
                           LLVMBool Debug, LLVMBool VerifyEach,
                           const char *Passes);

Arcanist question: to update an existing revision on Phab, would I run arc diff --update D102136 with my new changes?

[supergrecko]

[NewPM][C-bindings] Keep PassBuilder private to LLVMRunPasses and enable StandardInstrumentations

Edit: Looks like I only pushed my latest local git commit with arc diff by accident. This diff should be ignored.

[supergrecko]

[NewPM][C-bindings] Keep PassBuilder private to LLVMRunPasses and enable StandardInstrumentation

Edit: I once again messed up my arc diff. This one should also be ignored.

[supergrecko]

[NewPM][C-bindings] Keep PassBuilder private to LLVMRunPasses and enable StandardInstrumentation

[supergrecko]

Okay so I had some troubles with arc, but I think I finally got it right. I've now refactored LLVMRunPassBuilder into LLVMRunPasses with the changes we went through earlier and I've added the StandardInstrumentations inside of that function.

Apologies for the arcanist trouble

[aeubanks]

looks pretty good, just one nit

llvm/include/llvm-c/Transforms/PassBuilder.h

46

We should also move Debug and VerifyEach into their own separate options. We might make changes to these options (as I'm doing right now for DebugLogging), so we shouldn't tie down the exact option types into the main LLVMRunPasses API.

Maybe instead of LLVMPipelineTuningOptionsRef, we just have some generic LLVMPassBuilderOptionsRef which includes a PTO and these Debug/VerifyEach bools. That way if we want to change exactly how Debug works in the future, we can change the LLVMPassBuilderOptions underlying struct, and we only need to deprecate a separate API, not the main LLVMRunPasses. (or whatever naming you'd like)

[supergrecko]

[NewPM] Extract LLVMRunPasses options into LLVMPassBuilderOptionsRef

[supergrecko]

In D102136#2757551, @aeubanks wrote:

looks pretty good, just one nit

Good point. I have updated LLVMRunPasses to accept an LLVMPassBuilderOptionsRef which is currently a triplet of VerifyEach, DebugLogging and PipelineTuningOptions. I've made the construction/destruction/modification of this struct on the C-side equal to PipelineTuningOptions.

The llvm::LLVMPassBuilderOptions class is kept private to the bindings source because there shouldn't be a reason for anybody else to use this class. Right now I am using an assert for the LLVMPassBuilderOptionsRef->PTO to be present, but we could also change this to an LLVMErrorRef if that's preferable.

[aeubanks]

llvm/lib/Passes/PassBuilderBindings.cpp

36

can we just make this PipelineTuningOptions PTO? no need for a separate PTO instance. it makes the API more complicated than necessary (for example if someone just wants the default settings)
and we can just pass LLVMPassBuilderOptionsRef to the PTO APIs instead of exposing LLVMPipelineTuningOptionsRef

[supergrecko]

[NewPM] Abstract PipelineTuningOptions away into LLVMPassBuilderOptions

[aeubanks]

looks good aside from one super duper nit
do you have commit permission?

llvm/include/llvm-c/Transforms/PassBuilder.h

49–51

super duper nit, I'd move the module first, passes string second, TM third, and options fourth, so that the more important things are the earlier parameters

[supergrecko]

[NewPM] Re-arrange order of arguments for LLVMRunPasses

[supergrecko]

In D102136#2760416, @aeubanks wrote:

looks good aside from one super duper nit
do you have commit permission?

No, I do not have commit access. Not sure what information you need to attribute me as commit author, email is [e-mail], GitHub username is supergrecko, name is Mats Larsen. Let me know if there's anything else you need.

[aeubanks]

arc patch seems to have preserved your email/name so that's all taken care of.
Thanks for doing this!
I'll wait a bit to see if anybody else has comments.

[supergrecko]

Found a tiny mistake in one of the comments, will fix.

llvm/include/llvm-c/Transforms/PassBuilder.h

43–47

Just realized that these lines don't make any sense anymore after we moved them out into PassBuilderOptions.

[supergrecko]

[NewPM] Remove documentation comments for parameters that were refactored into LLVMPassBuilderOptionsRef

[steakhal]

In D102136#2761438, @supergrecko wrote:

[NewPM] Remove documentation comments for parameters that were refactored into LLVMPassBuilderOptionsRef

I think it doesn't build. Could you check if this is the case? @aeubanks

[thakis]

This doesn't build. I reverted it for now in 0b3397787222. Ideally, build locally, failing that wait for the presubmit bot to complete, failing that please watch bots after committing.

[thakis]

(example failure: https://lab.llvm.org/buildbot/#/builders/139/builds/4180)

[aeubanks]

sorry about that, I'll be more diligent about actually making sure a patch works before submitting

[supergrecko]

It looks like my local branch was a bit behind tip of tree when I started working on it which meant that https://reviews.llvm.org/rG34a8a437bf20e0a340c19ed1fdb9cca584d43da1 wasn't checked into my local branch.

My bad for not rebasing against main while working on it and thank you @aeubanks for fixing it!

[hctim]

Looks like this causes an ASan buildbot failure. I've left inline comments:

https://lab.llvm.org/buildbot/#/builders/5/builds/7712/

=================================================================
==88767==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 25 byte(s) in 1 object(s) allocated from:
    #0 0x212ffc4 in strdup /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors.cpp:439:3
    #1 0x2b8c0cf in LLVMGetDefaultTargetTriple /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/TargetMachineC.cpp:246:10
    #2 0x21725ed in PassBuilderCTest::SetUp() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/unittests/Passes/PassBuilderBindingsTest.cpp:19:26
    #3 0x34f7e88 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc
    #4 0x34f7e88 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2503:3
    #5 0x34fa90c in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2684:11
    #6 0x34fbcd0 in testing::TestSuite::Run() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2816:28
    #7 0x352b1b1 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:5338:44
    #8 0x352961c in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc
    #9 0x352961c in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:4925:10
    #10 0x34e58e0 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/googletest/include/gtest/gtest.h:2473:46
    #11 0x34e58e0 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50:10
    #12 0x7f76b899d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
SUMMARY: AddressSanitizer: 25 byte(s) leaked in 1 allocation(s).

llvm/unittests/Passes/PassBuilderBindingsTest.cpp

19

/*===-- Triple ------------------------------------------------------------===*/
/** Get a triple for the host machine as a string. The result needs to be
  disposed with LLVMDisposeMessage. */
char* LLVMGetDefaultTargetTriple(void);

Memory leak here caused by not calling LLVMDisposeMessage(Triple).

[aeubanks]

llvm/unittests/Passes/PassBuilderBindingsTest.cpp

19

fixed in ceb1ac9812cb0972cfa34cecc5e5704ae2a22063

[aaron.ballman]

FWIW, it looks like this has broken the fast Windows builder: https://lab.llvm.org/buildbot/#/builders/86/builds/13664

[aeubanks]

In D102136#2766265, @aaron.ballman wrote:

FWIW, it looks like this has broken the fast Windows builder: https://lab.llvm.org/buildbot/#/builders/86/builds/13664

5c291482ec8bcd686044ebc0d4cffe7bf769521c should hopefully fix that

llvm/include/llvm-c/Transforms/PassBuilder.h

+/*===-- llvm-c/Transform/PassBuilder.h - PassBuilder for LLVM C ---*- C -*-===*\
+|*                                                                            *|
+|* Part of the LLVM Project, under the Apache License v2.0 with LLVM          *|
+|* Exceptions.                                                                *|
+|* See https://llvm.org/LICENSE.txt for license information.                  *|
+|* SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception                    *|
+|*                                                                            *|
+|*===----------------------------------------------------------------------===*|
+|*                                                                            *|
+|* This header contains the LLVM-C interface into the new pass manager        *|
+|*                                                                            *|
+\*===----------------------------------------------------------------------===*/
+
+#ifndef LLVM_C_TRANSFORMS_PASSBUILDER_H
+#define LLVM_C_TRANSFORMS_PASSBUILDER_H
+
+#include "llvm-c/Error.h"
+#include "llvm-c/TargetMachine.h"
+#include "llvm-c/Types.h"
+
+LLVM_C_EXTERN_C_BEGIN
+
+/**
+ * A set of options passed which are attached to the Pass Manager upon run.
+ *
+ * This corresponds to an llvm::LLVMPassBuilderOptions instance
+ *
+ * The details for how the different properties of this structure are used can
+ * be found in the source for LLVMRunPasses
+ */
+typedef struct LLVMOpaquePassBuilderOptions *LLVMPassBuilderOptionsRef;
+
+/**
+ * Construct and run a set of passes over a module
+ *
+ * This function takes a string with the passes that should be used. The format
+ * of this string is the same as opt's -passes argument for the new pass
+ * manager. Individual passes may be specified, separated by commas. Full
+ * pipelines may also be invoked using `default<O3>` and friends. See opt for
+ * full reference of the Passes format.
+ */
+LLVMErrorRef LLVMRunPasses(LLVMModuleRef M, const char *Passes,
+                           LLVMTargetMachineRef TM,
+                           LLVMPassBuilderOptionsRef Options);
+
+/**
+ * Create a new set of options for a PassBuilder
+ *
+ * Ownership of the returned instance is given to the client, and they are
+ * responsible for it. The client should call LLVMDisposePassBuilderOptions
+ * to free the pass builder options.
+ */
+LLVMPassBuilderOptionsRef LLVMCreatePassBuilderOptions();
+
+/**
+ * Toggle adding the VerifierPass for the PassBuilder, ensuring all functions
+ * inside the module is valid.
+ */
+void LLVMPassBuilderOptionsSetVerifyEach(LLVMPassBuilderOptionsRef Options,
+                                         LLVMBool VerifyEach);
+
+/**
+ * Toggle debug logging when running the PassBuilder
+ */
+void LLVMPassBuilderOptionsSetDebugLogging(LLVMPassBuilderOptionsRef Options,
+                                           LLVMBool DebugLogging);
+
+void LLVMPassBuilderOptionsSetLoopInterleaving(
+    LLVMPassBuilderOptionsRef Options, LLVMBool LoopInterleaving);
+
+void LLVMPassBuilderOptionsSetLoopVectorization(
+    LLVMPassBuilderOptionsRef Options, LLVMBool LoopVectorization);
+
+void LLVMPassBuilderOptionsSetSLPVectorization(
+    LLVMPassBuilderOptionsRef Options, LLVMBool SLPVectorization);
+
+void LLVMPassBuilderOptionsSetLoopUnrolling(LLVMPassBuilderOptionsRef Options,
+                                            LLVMBool LoopUnrolling);
+
+void LLVMPassBuilderOptionsSetForgetAllSCEVInLoopUnroll(
+    LLVMPassBuilderOptionsRef Options, LLVMBool ForgetAllSCEVInLoopUnroll);
+
+void LLVMPassBuilderOptionsSetCoroutines(LLVMPassBuilderOptionsRef Options,
+                                         LLVMBool Coroutines);
+
+void LLVMPassBuilderOptionsSetLicmMssaOptCap(LLVMPassBuilderOptionsRef Options,
+                                             unsigned LicmMssaOptCap);
+
+void LLVMPassBuilderOptionsSetLicmMssaNoAccForPromotionCap(
+    LLVMPassBuilderOptionsRef Options, unsigned LicmMssaNoAccForPromotionCap);
+
+void LLVMPassBuilderOptionsSetCallGraphProfile(
+    LLVMPassBuilderOptionsRef Options, LLVMBool CallGraphProfile);
+
+void LLVMPassBuilderOptionsSetMergeFunctions(LLVMPassBuilderOptionsRef Options,
+                                             LLVMBool MergeFunctions);
+
+/**
+ * Dispose of a heap-allocated PassBuilderOptions instance
+ */
+void LLVMDisposePassBuilderOptions(LLVMPassBuilderOptionsRef Options);
+
+LLVM_C_EXTERN_C_END
+
+#endif // LLVM_C_TRANSFORMS_PASSBUILDER_H

llvm/lib/Passes/CMakeLists.txt

 add_llvm_component_library(LLVMPasses
   PassBuilder.cpp
+  PassBuilderBindings.cpp
   PassPlugin.cpp
   StandardInstrumentations.cpp
 
   ADDITIONAL_HEADER_DIRS
   ${LLVM_MAIN_INCLUDE_DIR}/llvm
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/Passes
 
   DEPENDS

llvm/lib/Passes/PassBuilderBindings.cpp

+//===-------------- PassBuilder bindings for LLVM-C -----------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+/// \file
+///
+/// This file defines the C bindings to the new pass manager
+///
+//===----------------------------------------------------------------------===//
+
+#include "llvm-c/Transforms/PassBuilder.h"
+#include "llvm/IR/Verifier.h"
+#include "llvm/Passes/PassBuilder.h"
+#include "llvm/Passes/StandardInstrumentations.h"
+#include "llvm/Support/CBindingWrapping.h"
+
+using namespace llvm;
+
+namespace llvm {
+/// Helper struct for holding a set of builder options for LLVMRunPasses. This
+/// structure is used to keep LLVMRunPasses backwards compatible with future
+/// versions in case we modify the options the new Pass Manager utilizes.
+class LLVMPassBuilderOptions {
+public:
+  explicit LLVMPassBuilderOptions(
+      bool DebugLogging = false, bool VerifyEach = false,
+      PipelineTuningOptions PTO = PipelineTuningOptions())
+      : DebugLogging(DebugLogging), VerifyEach(VerifyEach), PTO(PTO) {}
+
+  bool DebugLogging;
+  bool VerifyEach;
+  PipelineTuningOptions PTO;
+};
+} // namespace llvm
+
+static TargetMachine *unwrap(LLVMTargetMachineRef P) {
+  return reinterpret_cast<TargetMachine *>(P);
+}
+
+DEFINE_SIMPLE_CONVERSION_FUNCTIONS(LLVMPassBuilderOptions,
+                                   LLVMPassBuilderOptionsRef)
+
+LLVMErrorRef LLVMRunPasses(LLVMModuleRef M, const char *Passes,
+                           LLVMTargetMachineRef TM,
+                           LLVMPassBuilderOptionsRef Options) {
+  TargetMachine *Machine = unwrap(TM);
+  LLVMPassBuilderOptions *PassOpts = unwrap(Options);
+  bool Debug = PassOpts->DebugLogging;
+  bool VerifyEach = PassOpts->VerifyEach;
+
+  Module *Mod = unwrap(M);
+  PassInstrumentationCallbacks PIC;
+  PassBuilder PB(Debug, Machine, PassOpts->PTO, None, &PIC);
+
+  LoopAnalysisManager LAM(Debug);
+  FunctionAnalysisManager FAM(Debug);
+  CGSCCAnalysisManager CGAM(Debug);
+  ModuleAnalysisManager MAM(Debug);
+  PB.registerLoopAnalyses(LAM);
+  PB.registerFunctionAnalyses(FAM);
+  PB.registerCGSCCAnalyses(CGAM);
+  PB.registerModuleAnalyses(MAM);
+  PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
+
+  StandardInstrumentations SI(Debug, VerifyEach);
+  SI.registerCallbacks(PIC, &FAM);
+  ModulePassManager MPM(Debug);
+  if (VerifyEach) {
+    MPM.addPass(VerifierPass());
+  }
+  if (auto Err = PB.parsePassPipeline(MPM, Passes)) {
+    return wrap(std::move(Err));
+  }
+
+  MPM.run(*Mod, MAM);
+  return LLVMErrorSuccess;
+}
+
+LLVMPassBuilderOptionsRef LLVMCreatePassBuilderOptions() {
+  return wrap(new LLVMPassBuilderOptions());
+}
+
+void LLVMPassBuilderOptionsSetVerifyEach(LLVMPassBuilderOptionsRef Options,
+                                         LLVMBool VerifyEach) {
+  unwrap(Options)->VerifyEach = VerifyEach;
+}
+
+void LLVMPassBuilderOptionsSetDebugLogging(LLVMPassBuilderOptionsRef Options,
+                                           LLVMBool DebugLogging) {
+  unwrap(Options)->DebugLogging = DebugLogging;
+}
+
+void LLVMPassBuilderOptionsSetLoopInterleaving(
+    LLVMPassBuilderOptionsRef Options, LLVMBool LoopInterleaving) {
+  unwrap(Options)->PTO.LoopInterleaving = LoopInterleaving;
+}
+
+void LLVMPassBuilderOptionsSetLoopVectorization(
+    LLVMPassBuilderOptionsRef Options, LLVMBool LoopVectorization) {
+  unwrap(Options)->PTO.LoopVectorization = LoopVectorization;
+}
+
+void LLVMPassBuilderOptionsSetSLPVectorization(
+    LLVMPassBuilderOptionsRef Options, LLVMBool SLPVectorization) {
+  unwrap(Options)->PTO.SLPVectorization = SLPVectorization;
+}
+
+void LLVMPassBuilderOptionsSetLoopUnrolling(LLVMPassBuilderOptionsRef Options,
+                                            LLVMBool LoopUnrolling) {
+  unwrap(Options)->PTO.LoopUnrolling = LoopUnrolling;
+}
+
+void LLVMPassBuilderOptionsSetForgetAllSCEVInLoopUnroll(
+    LLVMPassBuilderOptionsRef Options, LLVMBool ForgetAllSCEVInLoopUnroll) {
+  unwrap(Options)->PTO.ForgetAllSCEVInLoopUnroll = ForgetAllSCEVInLoopUnroll;
+}
+
+void LLVMPassBuilderOptionsSetCoroutines(LLVMPassBuilderOptionsRef Options,
+                                         LLVMBool Coroutines) {
+  unwrap(Options)->PTO.Coroutines = Coroutines;
+}
+
+void LLVMPassBuilderOptionsSetLicmMssaOptCap(LLVMPassBuilderOptionsRef Options,
+                                             unsigned LicmMssaOptCap) {
+  unwrap(Options)->PTO.LicmMssaOptCap = LicmMssaOptCap;
+}
+
+void LLVMPassBuilderOptionsSetLicmMssaNoAccForPromotionCap(
+    LLVMPassBuilderOptionsRef Options, unsigned LicmMssaNoAccForPromotionCap) {
+  unwrap(Options)->PTO.LicmMssaNoAccForPromotionCap =
+      LicmMssaNoAccForPromotionCap;
+}
+
+void LLVMPassBuilderOptionsSetCallGraphProfile(
+    LLVMPassBuilderOptionsRef Options, LLVMBool CallGraphProfile) {
+  unwrap(Options)->PTO.CallGraphProfile = CallGraphProfile;
+}
+
+void LLVMPassBuilderOptionsSetMergeFunctions(LLVMPassBuilderOptionsRef Options,
+                                             LLVMBool MergeFunctions) {
+  unwrap(Options)->PTO.MergeFunctions = MergeFunctions;
+}
+
+void LLVMDisposePassBuilderOptions(LLVMPassBuilderOptionsRef Options) {
+  delete unwrap(Options);
+}

llvm/unittests/Passes/CMakeLists.txt

 # Needed by LLVM's CMake checks because this file defines multiple targets.
-set(LLVM_OPTIONAL_SOURCES PluginsTest.cpp TestPlugin.cpp)
+set(LLVM_OPTIONAL_SOURCES PluginsTest.cpp TestPlugin.cpp PassBuilderBindingsTest.cpp)
 
 # If plugins are disabled, this test will disable itself at runtime. Otherwise,
 # reconfiguring with plugins disabled will leave behind a stale executable.
 if (LLVM_ENABLE_PLUGINS)
   add_definitions(-DLLVM_ENABLE_PLUGINS)
 endif()
 
 # The plugin expects to not link against the Support and Core libraries,
set_output_directory(TestPlugin
     BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
     LIBRARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
     )
   set_target_properties(TestPlugin PROPERTIES FOLDER "Tests")
 
   add_dependencies(TestPlugin intrinsics_gen)
   add_dependencies(PluginsTests TestPlugin)
 endif()
+
+set(LLVM_LINK_COMPONENTS Support Passes Core Target native)
+add_llvm_unittest(PassesBindingsTests PassBuilderBindingsTest.cpp)
+target_link_libraries(PassesBindingsTests PRIVATE LLVMTestingSupport)
 No newline at end of file

llvm/unittests/Passes/PassBuilderBindingsTest.cpp

+//===- unittests/Passes/PassBuilderBindingsTest.cpp -----------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "llvm-c/Core.h"
+#include "llvm-c/Transforms/PassBuilder.h"
+#include "llvm-c/Types.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+
+class PassBuilderCTest : public testing::Test {
+  void SetUp() override {
+    LLVMInitializeNativeTarget();
+    const char *Triple = LLVMGetDefaultTargetTriple();
+    char *Err;
+    LLVMTargetRef Target;
+    if (LLVMGetTargetFromTriple(Triple, &Target, &Err)) {
+      FAIL() << "Failed to create target from default triple: " << Err;
+    }
+    TM = LLVMCreateTargetMachine(Target, Triple, "generic", "",
+                                 LLVMCodeGenLevelDefault, LLVMRelocDefault,
+                                 LLVMCodeModelDefault);
+    Context = LLVMContextCreate();
+    Module = LLVMModuleCreateWithNameInContext("test", Context);
+  }
+
+  void TearDown() override {
+    LLVMDisposeTargetMachine(TM);
+    LLVMDisposeModule(Module);
+    LLVMContextDispose(Context);
+  }
+
+public:
+  LLVMTargetMachineRef TM;
+  LLVMModuleRef Module;
+  LLVMContextRef Context;
+};
+
+TEST_F(PassBuilderCTest, Basic) {
+  LLVMPassBuilderOptionsRef Options = LLVMCreatePassBuilderOptions();
+  LLVMPassBuilderOptionsSetLoopUnrolling(Options, 1);
+  LLVMPassBuilderOptionsSetVerifyEach(Options, 1);
+  LLVMPassBuilderOptionsSetDebugLogging(Options, 0);
+  if (LLVMErrorRef E = LLVMRunPasses(TM, Module, Options, "default<O2>")) {
+    char *Msg = LLVMGetErrorMessage(E);
+    LLVMConsumeError(E);
+    LLVMDisposePassBuilderOptions(Options);
+    FAIL() << "Failed to run passes: " << Msg;
+  }
+  LLVMDisposePassBuilderOptions(Options);
+}
+
+TEST_F(PassBuilderCTest, InvalidPassIsError) {
+  LLVMPassBuilderOptionsRef Options = LLVMCreatePassBuilderOptions();
+  LLVMErrorRef E1 = LLVMRunPasses(TM, Module, Options, "");
+  LLVMErrorRef E2 = LLVMRunPasses(TM, Module, Options, "does-not-exist-pass");
+  ASSERT_TRUE(E1);
+  ASSERT_TRUE(E2);
+  LLVMConsumeError(E1);
+  LLVMConsumeError(E2);
+  LLVMDisposePassBuilderOptions(Options);
+}