During review of JDK-8371146 we came across the fact that we do most likely not set the ctrl of the nodes from the speculative checks and alignment expression for pre-loop limit.

Some values/nodes we use have ctrl after the pre-loop, but early before. We then use it before the pre-loop, but do not update the ctrl of that node, nor any of its inputs which may also have ctrl after pre-loop. That means we use those nodes before pre-loop, but their ctrl is after, and that is incorrect. We should probably adjust the ctrl of all relevant nodes, both for alignment and for speculative checks.

So far, there has not been a bug, because it is unlikely that SuperWord itself or another loop optimization afterwards (only those that do not require major progress to be set) use the incorrect ctrl. But we can't be 100% sure this is not an issue.

Longterm, we should improve loop opts verification (JDK-8307982 and related issues). We should make sure that such a verification pass is called after SuperWord. That would give us a good basis for fixing the ctrl during SuperWord, and give us good confidence that the fix is correct. I would not feel comfortable fixing ctrl without verification - it would be like flying blind - it is too easy to get it wrong and cause bugs because of it.

I'm filing this as a bug, though it would only be a low-priority bug. The issue is already older, since we have been using alignment for a long time. But things are now getting worse since we are adding more checks, and so more nodes are going to have incorrect ctrl. We could also consider turning this into an RFE.