This patch removes the function expandSCEVIfNeeded which behaves not as
it was intended. This function tries to make a lookup for exact existing expansion
and only goes to normal expansion via expandCodeFor if this lookup hasn't found
anything. As a result of this, if some instruction above the loop has a SCEVConstant
SCEV, this logic will return this instruction when asked for this SCEVConstant rather
than return a constant value. This is both non-profitable and in some cases leads to
breach of LCSSA form (as in PR38674).
Whether or not it is possible to break LCSSA with this algorithm and with some
non-constant SCEVs is still in question, this is still being investigated. I wasn't
able to construct such a test so far, so maybe this situation is impossible. If it is,
it will go as a separate fix.
Rather than do it, it is always correct to just invoke expandCodeFor unconditionally:
it behaves smarter about insertion points, and as side effect of this it will choose a
constant value for SCEVConstants. For other SCEVs it may end up finding a better insertion
point. So it should not be worse in any case.
Is it really necessary to check all of the generated IR like this? Could the test be written to only check the instructions participating in the LCSSA value flow? If so, it would make the test more robust.