In Julia, we have LLVM.jl as a wrapper for the LLVM C API, with some extra API entrypoints much like other projects. After the introduction of the new pass manager, we used to maintain C APIs that exposed much of the NewPM C++ API (e.g., PassManagers, PassBuilders, etc). However, we were told that the string-based API is basically the way forward, so we recently switched to LLVMRunPasses.
There seem to be a couple of things missing from that API, or at least that I’m not sure how to do:
is it possible to run a pass on a single/specific function? if not, would it be reasonable to extend LLVMRunPasses to accept both modules and functions, and dynamically switch between parsePassPipeline(MPM) and parsePassPipeline(FPM)?
how do I specify which alias analysis to use? opt seems to have -aa-pipeline, so should this be a new passes argument to LLVMRunPasses, or could it be added to the existing pass pipeline string (aa(basic-aa) or something)?
how do I have LLVM automatically run target-registered passes? for example, with NVPTX I would like LLVM to automatically run NVVMReflect and NVVMIntrRangePass which NVPTX registers through pipeline extension points. currently, it looks like these callbacks (e.g. PipelineStartEPCallback) are only used by the default pipeline builder, not when using a custom pipeline. is there a solution to this, or would it be reasonable to e.g. encode extension points in the pass pipeline string?
For things that currently aren’t possible, I’d appreciate thoughts on how to implement them. I can prototype things in LLVM.jl’s libLLVMExtra and upstream them afterwards, so it’s good to start out with something that’s likely to be accepted.
Not sure what you mean by accept both, but adding something like LLVMRunPassesOnFunction should be fine.
I don’t think this is supported currently. The easiest way would probably be to add the AA pipeline to LLVMPassBuilderOptions?
Interesting. The only idea I have for this is to support some pseudo-passes like callback<pipeline-start> to the pipeline parse, which call invokePipelineStartEPCallbacks() and similar. Though it’s a bit trickier than that, as these also have an optimization level argument, and there’s also a proposal to pass the thin/full LTO phase to them.
Yeah I got myself confused that an isa would work here. I’ll add a new entrypoint.
Yes, that does seem easier. Integrating with the pipeline string seemed more idiomatic, and I figured I have to touch that code anyway for the extension points, but I’m happy with either solution.
Even though the C++ API of PassBuilder returns a ModulePassManager and then you run that on a Module, the C API doesn’t expose any pass manager infra. We could also make the pipeline string part of LLVMPassBuilderOptions for consistency, along with some helper functions to set it to the default optimization pipelines like default<O3>.
What would be the difference between that and just using default<O3> as the pipeline string? And relatedly: Why aren’t the PipelineTuningOptions similarly exposed as string arguments, e.g., default<O3;loop_interleaving=false>?