`PhaseIterGVN::optimize()` is responsible for running Ideal (and friends) until hopefully fixpoint by iterating on a worklist of nodes to idealize. `transform_old` is run on each node, and then, if there is a change and PrintIdealGraphLevel/IGVPrintLevel is high enough, we print the graph (of the phase if PhasePrintLevel/PrintPhaseLevel is high enough).
The problem lies in the detection of changes. Currently, in `PhaseIterGVN::trace_PhaseIterGVN` we can see:
```cpp
const Type* newtype = type_or_null(n);
if (nn != n || oldtype != newtype) {
C->print_method(PHASE_AFTER_ITER_GVN_STEP, 5, n);
}
```
so we print iff the node was replaced or the type changed. But it's not always the case: it's possible to rewire the graph around, `return this;` and not have a better type (typically, for control nodes, the type will always be `CONTROL` or a tuple of that).
The consequence is that even with PrintIdealGraphLevel as high as we want, some steps can happen (idealization of some nodes makes changes), but that won't appear in IGV (or phase logging...). The next step will show the changes of the "silent" step too, which can be confusing.
We could try to improve the detection of changes in multiple way. We could instead/in addition use the `_modified_nodes` list (which is not foolproof either). Or we could make `transform_old` track if a modification happened and return a boolean for that. Other options may exist.
The problem lies in the detection of changes. Currently, in `PhaseIterGVN::trace_PhaseIterGVN` we can see:
```cpp
const Type* newtype = type_or_null(n);
if (nn != n || oldtype != newtype) {
C->print_method(PHASE_AFTER_ITER_GVN_STEP, 5, n);
}
```
so we print iff the node was replaced or the type changed. But it's not always the case: it's possible to rewire the graph around, `return this;` and not have a better type (typically, for control nodes, the type will always be `CONTROL` or a tuple of that).
The consequence is that even with PrintIdealGraphLevel as high as we want, some steps can happen (idealization of some nodes makes changes), but that won't appear in IGV (or phase logging...). The next step will show the changes of the "silent" step too, which can be confusing.
We could try to improve the detection of changes in multiple way. We could instead/in addition use the `_modified_nodes` list (which is not foolproof either). Or we could make `transform_old` track if a modification happened and return a boolean for that. Other options may exist.