If -enable-constraint-elimination is specified, add it to the -O2/-O3 pipeline.
(-O1 uses a separate function now.)
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
thanks!
llvm/include/llvm/Transforms/Scalar/ConstraintElimination.h | ||
---|---|---|
17 | this shouldn't be needed |
llvm/lib/Passes/PassBuilder.cpp | ||
---|---|---|
611 | I add it here to emulate to legacy pass manager builder's behavior. I wonder whether the intention is to move some stuff from CorrelatedValuePropagationPass to ConstraintEliminationPass. Does it make sense to place ConstraintEliminationPass before/after CorrelatedValuePropagationPass? |
Thanks for adding NPM support! Not sure if all tests should be also updated to add NPM run-lines.
llvm/lib/Passes/PassBuilder.cpp | ||
---|---|---|
611 | The pass is quite new and not too much experimenting went into finding he ideal position in the pipeline. I expect the position to be adjusted as it evolves. It currently works best when most original conditions are still exposed and branches are used. There is some overlap with CVP, but the main use case is handling cases that are not handled by CVP (or any other pass). | |
llvm/lib/Transforms/Scalar/ConstraintElimination.cpp | ||
14 | IIRC clang-format will sort the includes, so it might be best to move it to the final position? |
llvm/lib/Passes/PassBuilder.cpp | ||
---|---|---|
611 | Thanks for the reply. I'll keep it as is (having a consistent position with the legacy PM) | |
llvm/lib/Transforms/Scalar/ConstraintElimination.cpp | ||
14 | This is the final position. The coding standard prefers the main header as the first. clang-format does this (the main header gets the category 0 and has the highest priority). |
this shouldn't be needed