You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running the ACCEPT passes currently requires invoking opt or whatever with the -O1 optimization level, which wastes time since we don't need all those other optimizations at this point. It should instead be possible to run ACCEPT optimizations in isolation.
However, we can't do this now since it seems to be impossible to cleanly require an analysis pass from a FunctionPass. That is, using addRequired<>() from the getAnalysisUsage method in a FunctionPass leads to an assertion failure along the lines of "Unable to schedule…". As far as I can tell this is by design. It may be solved in later LLVM versions, which have recently undergone a complete refactor of the pass manager system. Or we could move to ModulePasses.
The text was updated successfully, but these errors were encountered:
Running the ACCEPT passes currently requires invoking
opt
or whatever with the-O1
optimization level, which wastes time since we don't need all those other optimizations at this point. It should instead be possible to run ACCEPT optimizations in isolation.However, we can't do this now since it seems to be impossible to cleanly require an analysis pass from a FunctionPass. That is, using
addRequired<>()
from thegetAnalysisUsage
method in aFunctionPass
leads to an assertion failure along the lines of "Unable to schedule…". As far as I can tell this is by design. It may be solved in later LLVM versions, which have recently undergone a complete refactor of the pass manager system. Or we could move toModulePass
es.The text was updated successfully, but these errors were encountered: