JS: improve join-order for Configuration::barrierGuardBlocksEdge #5210
Conversation
erik-krogh
added
the
Awaiting evaluation
erik-krogh
force-pushed
the
barrierPerf
branch
from
cad624a to
814b557
Compare
erik-krogh
removed
the
Awaiting evaluation
| * | ||
| * This predicate exists to get a better join-order for the `barrierGuardBlocksEdge` predicate above. | ||
| */ | ||
| private BasicBlock getADominatedBasicBlock(BarrierGuardNode guard, ConditionGuardNode cond) { |
There was a problem hiding this comment.
Should this perhaps be pragma[noinline] to prevent the compiler from inlining the predicate and discovering the bad join order again?
There was a problem hiding this comment.
Maybe.
I prefer not to.
If the compiler is changed such that it inlines the predicate, it might also be changed such that it discovers a better join order.
If we use a pragma, we force the compiler to use the current join order, even if something better is possible in the future.
|
Can you hold off on this until after the Redux PR is merged, or run an evaluation of it based on that? It changes the |
OK that was a bad suggestion given that it just hit the BDD node limit again. Nevermind. |
The predicate went from ~40s to ~100ms when running
TaintedPath.qlonace.The goal of my reordering was mostly to get
barrierGuardIsRelevantearlier in the join-order.