Remove bindings for LLVM's legacy optimization passes

[MaskRay]

Related to #5

In LLVM, "Using the legacy pass manager for the optimization pipeline is deprecated" since 13.0.0 ( https://releases.llvm.org/13.0.0/docs/ReleaseNotes.html#changes-to-the-llvm-ir). Many passes have been removed or are being removed for 16.0 and 17.0.

A lot of wrappers in ffi/passmanagers.cpp should be removed since the wrapped C ABIs have been removed by https://github.com/llvm/llvm-project . I am not familiar with the project but from a glance the two files need most changes.

These lines in ffi/initfini.cpp will be broken by https://reviews.llvm.org/D145043

 INIT(Core)
 ...

ffi/passmanagers.cpp

 API_EXPORT(int)
@@ -143,60 +124,9 @@
 }

 API_EXPORT(void)
-LLVMPY_AddAAEvalPass(LLVMPassManagerRef PM) {
-    unwrap(PM)->add(llvm::createAAEvalPass());
-}
-
-API_EXPORT(void)
-LLVMPY_AddBasicAAWrapperPass(LLVMPassManagerRef PM) {
-    unwrap(PM)->add(llvm::createBasicAAWrapperPass());
-}
-
-API_EXPORT(void)
-LLVMPY_AddDependenceAnalysisPass(LLVMPassManagerRef PM) {
-    unwrap(PM)->add(llvm::createDependenceAnalysisWrapperPass());
-}
-
-API_EXPORT(void)
-LLVMPY_AddCallGraphDOTPrinterPass(LLVMPassManagerRef PM) {
-    unwrap(PM)->add(llvm::createCallGraphDOTPrinterPass());
-}
...

[folded]

Here are some points that have arisen from the internal work to move to the new pass manager without changing llvmlite APIs too much:

• PassManager native objects should be ephemeral, so PassManager itself shouldn't hold on to a reference to an LLVM object; just pass the required configuration information to native code and construct when applied.
• PassManagerBuilder can hold all of its state as a python object rather than calling LLVM methods, and then update the PassManager. This keeps the current API the same. Similarly for TargetMachine, although this should still probably be backed by a native object.
• Passes that are added explicitly can also be stored as python data in a PassManager, and then applied on run.
  • Passes can be represented by strings - but the level (module, function, loop) needs to be known, and sometimes explicit analysis passes need to be run before other stages, which is something that legacy pass manager organised for you. Also there can be a pretty complex nesting structure. It seems like it might be sensible to minimise the API here to just what numba needs, and provide something generic to other users that can be used to create more generic chains of passes, punting most of the complexity.
• It might be possible to run the custom refprune pass directly (and the precondition passes), without needing to create a PassManager.

These aren't ready for an upstream commit yet, but I'll be proposing some PRs with components the above to address this bug once things are less in flux.

[MaskRay]

Just wanted to check back here. The code will soon fail to compile with latest llvm-project. (https://reviews.llvm.org/D145043#4232771)

[folded]

llvmlite isn't intended to compile against recent LLVM versions, so I think the urgency to llvmlite is not great. However I do think that there should be a plan made for this that considers the llvmlite release schedule, since it's not possible to make this switch without breaking some existing llvmlite APIs. It would probably be better if pass management in llvmlite were abstracted somewhat, and didn't try to expose the C API 1:1, given that almost nothing needs the flexibility to completely configure a pass pipeline.