[llvm-dev] OptBisect implementation for new pass manager (original) (raw)

Fedor Sergeev via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 1 11:32:16 PDT 2018

On 10/01/2018 08:39 PM, David Greene wrote:

"Kaylor, Andrew" <andrew.kaylor at intel.com> writes:

What if in the registration interface we had three options: skippable, not skippable, and run at OptLevel::None. I kind of like this idea. If necessary, the pass could even query the target (or some other entity) about what OptLevel::None means. If we have such query hooks, do we need "not skippable?" If a pass is not skippable, then running at OptLevel::None should be fine, as long as the pass can know what it needs to do at OptLevel::None (at minimum produce functional code). "Not skippable" seems to imply "run the pass at full(-ish) optimization always." Maybe that's a useful third state, I'm not sure. Seems like our current vocabulary is somewhat imprecise.

I'm not sure that I fully gather which part of pipeline construction/execution and which object interaction do you mean when talking about "query hooks" or "run the pass".

Right now we have the following objects:    - OptBisect, which is pass-instrumentation object    - PassBuilder object that constructs the pipeline    - PassManager object that controls the pass execution    - Pass object, which is being constructed for PassBuilder and then executed with PassManager

At construction time there are:   Pass, OptBisect, PassBuilder objects and at execution time there are:   Pass, OptBisect, PassManager objects which of those do you see interacting when you talk about "query hooks"?

My mental model of "not skippable" handling:   - OptBisect is the controlling object.   - at construction time it tracks objects being constructed and stores its "skippable"/"unskippable" properties.   - at run-time PassManager asks OptBisect and it reports whether to skip the pass or not.     PassManager acts accordingly.

"run the pass at full optimization" is something that I dont see a clear mental model of. Obviously it is the Pass itself that can run itself at full optimization if it gets control. PassManager can pass the control to the Pass. OptBisect does not run at all, it just advises the PassManager. How Pass decides that it runs at full optimization/half optimization?

(side note - it appears that for any kind of interaction we first should design the execution part of it, and only then go for the construction time)

regards,   Fedor.

More information about the llvm-dev mailing list