We are currently cloning and initializing Assertion Predicates from a source loop in reverse-order at the target loop out of convenience/simplicity and to make sure that set_ctrl() is as precise as possible.

The only place where we do a cloning in order is in Loop Unswitching since we wanted to reuse the existing create_if_for_new_predicate() method.

When revisiting this code, I wanted to replace it by a PredicateVisitor. However, while it is fine to reverse the order of Assertion Predicates, it is not for Parse Predicates. They require the same order at the unswitched loop versions. Therefore, we would need some special logic or a separate visitor just for Parse Predicates.

This suggests to revisit the reverse-order cloning/initializing of Assertion Predicates and fix that one instead. It would make the code easier and on top of that, we can easier reason about the graph and determine where an Assertion Predicate originally came from.

The only downside is that we need to set_ctrl() the involved data nodes at the old target loop entry because we are creating nodes from the tail end of the Assertion Predicate chain by adding them as new inputs to earlier created Assertion Predicates. While this is not as precise as it could be, it is still correct. In the next round of loop opts, set_ctrl() will be computed newly to set it to the best place determined by the heuristics.