[PATCH] D102136: [NewPM] Add C bindings for new pass manager

[Arthur Eubanks via Phabricator via llvm-commits]

aeubanks added a comment.

In D102136#2749071 <https://reviews.llvm.org/D102136#2749071>, @supergrecko wrote:

> In D102136#2748572 <https://reviews.llvm.org/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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102136/new/

https://reviews.llvm.org/D102136