This is an archive of the discontinued LLVM Phabricator instance.

POC. [PassBuilder] introduce a separate pass-pipeline parsing API
Needs ReviewPublic

Authored by fedor.sergeev on Apr 18 2019, 7:49 AM.

Details

Summary

Separating all the parsing APIs into PipelineParser. For now just a proof-of-concept.

Event Timeline

fedor.sergeev created this revision.Apr 18 2019, 7:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2019, 7:49 AM

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.