https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496
--- Comment #4 from Jeffrey A. Law <law at redhat dot com> --- More thoughts on how we might approach resolving. To tackle in the backwards threader I think we need to change the model for how backwards threading works. Right now it starts walking up the use-def chain to find a constant value for the given SSA_NAME. If it finds a constant, any constant, then we have a jump threading opportunity. We extract the conditional from the last block in the path, plug the constant into the right place and determine where it's going to go. Then we record the jump thread path. The conceptual change we need to make is to be able to raise the query "find paths with where X has a constant value and record those paths and the value found for X". That would allow us to do things like simplify a bit-and by determining if one operand is zero along a particular path. Then we can examine how that feeds a conditional. Note carefully how determining the object has a constant value other than 0 does not allow simplification. Given that kind of structure we could probably look to tackle this BZ in the backward threader. We could look to improve DOM's threader. Right now we don't pick up the secondary threading opportunities because of limitations imposed by our SSA graph updating code. Converting that code to use the SEME copier like the backwards threader uses would allow removal of that limitation and likely allow detection of at least some cascading jump threading effects. Anyway, I wanted to get those thoughts recorded here so they're not lost.
