Why?
Iterative dataflow problems, in particular, capturing second order effects, etc, are very well known things and often do not require solving the halting problem or anything like it.
Just propagating analysis facts around (IE "i can thread this jump"). In fact, i'm fairly confident standard jump threading (which this isn't quite) can be split into an analysis and optimization path.
This is because you already know what the CFG will look like if you perform a particular jump threading.
This is similar to PRE and other situations where you know what the end result of a given expression being PRE'd will be, and thus, you can figure out whether what the full end state of the transform will be, regardless of whether you do it.
In fact, if you couldn't do this, you couldn't do LCM as two unidirectional dataflow problems.
Jump threading seems much the same. Completely decomposable, regardless of whether you perform a given path of optimizations or not.
The only question is the expense of doing so.