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
handle cases where the redundant compare block has side effects. This still seems beyond our reach, as it requires code duplication and so may entail rather extensive revisions of the SSA graph. In particular, if the block has non-PHI SSA defs we need to be able to find and update all downstream uses, as well as introducing necessary PHIs. If the block has SSA uses they should be rewritten via PHI disambiguation (which as noted below can fail for some preds). Etc.
Seems like in some (perhaps many) cases the side effect is a simple assignment and we can get rid of it my making forward sub more aggressive, say handling QMARK. We see this in Type.IsInstance, for instance.
handle cases where the relop or the dominated branch is implicit (bounds check, say). Note bounds check optimizations use conservative VNs (so that we will still be memory safe in the presence of races) while the entire redundant branch optimizer currently uses liberal VNs).
or perhaps consider materializing bounds checks branches before running the optimizer. This is a more radical proposal but means we might not need specialized bounds-check specific optimizations.
use VNs more cleverly (instead of identical liberal vns, we can check if dominating exception vn set covers dominated exception vn set, and normal liberal VNs match).
Note I am also seeing cases now where we could do this optimization, but it is not possible to map from a PHI operand to the corresponding predecessor block, because we only record one PHI operand per SSA def, not one per predecessor. So, if two predecessors bring in the same SSA def they "share" a phi operand, but it only has room for one block number, and we lose the ability to reason about the other predecessor. Not clear how much impact this has or what a plausible fix might be (other than the obvious one of having one phi input per predecessor, which can cause its own headaches if there are huge join points and lots of SSA vars).
Look more critically at the modelling of exceptions in jump threading; it seems like we are perhaps not sufficiently rigorous in the screening we do. It could be that the various exclusions in the Check method and elsewhere eliminate most of the places where an exception could sneak past...?
handle predicates in returns (see next item for one case of this)
#43811 introduced a redundant branch optimization, further enhanced in #46237 and #46257.
There are still more improvements possible. Here's a partial list of ideas, issues, and improvements:
x > 0dominatingx == 0).fgOptimizeUncondBranchToSimpleCondx > 5dominatingx > 3)QMARK. We see this inType.IsInstance, for instance.AND,OR(would guessNOTis already handled by VN?).optJumpThreadon the basic block epochoptReachableon the visited BB flagsCheckmethod and elsewhere eliminate most of the places where an exception could sneak past...?category:cq
theme:redundant-branches
skill-level:expert
cost:large
impact:medium