Was originally implemented with Opaque2 node, but the optimization broke once we performed IGVN rounds after Opaque2 were removed from graph.

JDK-8294540: removed Opaque2 nodes as the implementation was now broken, and triggered an assert.

Idea:
Loops often use the un-incremented Phi trip-count after the loop-exit. For example one might track the last index in a loop. This means we have two registers used for the trip-count, one for the pre-incremented value, and one for the incremented value.
This is unnecessary, we can simply decrement the incremented value after loop exit, and save a register in the loop.

This optimization made sense many years ago, investigate if it still makes sense today with modern Processors that do many more advanced optimizations with registers.

The question is if one should take the old approach of Opaque2 nodes (please use a more descriptive name!), where we block optimizations explicitly during the whole compilation, or if we can detect such patterns at the end of all optimizations. Maybe this has to be done before matching / mach graph, but this is up to the person taking on this task.