Separating all the parsing APIs into PipelineParser. For now just a proof-of-concept.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 30735 Build 30734: arc lint + arc unit
Event Timeline
This is not yet complete (in particular parseAA is still in PassBuilder atm).
However I would like to get a feedback on overall organization.
Right now:
- PipelineParser is a nested class in PassBuilder
- it is created for a single text-pipeline-parsing query
- text is processed into a pipeline vector and kept in the parser
- callbacks still reside in pass builder, accessed through a reference to pass builder kept in the parser
- callbacks take both Parser and array of Elements
IMO it makes sense to separate parsing of the pipeline text and the pipeline tree more. Parsing the pipeline string into the tree of pipeline elements is an operation that happens once and as the very first thing, after which the string is not needed anymore. The PassBuilder could do that part, and then call the PipelineParser to further parse the tree. Otherwise this looks great!
llvm/include/llvm/Passes/PassBuilder.h | ||
---|---|---|
85 | Inner classes are auto-friends, are they not? |
To clarify that: Currently clients are offered two APIs to populate a PassManager: One that consumes PipelineElements and one that consumes a string. When you have a PipelineElement in hand, you could use both, because it's mostly just a StringRef! I'd like to avoid that ambiguity.
Inner classes are auto-friends, are they not?