In current implementation, definition of LCSSA is violated by tokens.
In fact, token values that are defined in loop can be sunk down the loop
without creation of LCSSA Phis for their token arguments. Later on, any
pass that expects that all in-loop values go through phis may produce
incorrect IR on it.
https://github.com/llvm/llvm-project/issues/56243 shows how it happens
to LoopSimplifyCFG that may break SSA form because it is unable to fix a
LCSSA Phi for token out going out of the loop. But potentially, any other
transform that relies on definition of LCSSA may be affected.
This patch prohibits LICM from introducing new out-of-loop users of
token defs. It does not fight the situation when such uses existed before
the transform.
This is not a full solution for this general problem. The full solution should
possibly revisit how we define LCSSA and tokens. It just addresses one case
of sinking. Note that LICM is not the only pass that may introduce an out-of-loop
use of token which didn't exist: for example, InstCombine can do the same.
They should be addressed separately, in a similar manner. So far I could not
create a real test that would crash on this, which doesn't mean there is no
problem.