Once we resolved an undef in a function we can run Solve, which could
lead to finding a constant return value for the function, which in turn
could turn undefs into constants in other functions that call it, before
resolving undefs there.
Computationally the amount of work we are doing stays the same, just the
order we process things is slightly different and potentially there are
a few less undefs to resolve.
We are still relying on the order of functions in the IR, which means
depending on the order, we are able to resolve the optimal undef first
or not. For example, if @test1 comes before @testf, we find the constant
return value of @testf too late and we cannot use it while solving
@test1.
This on its own does not lead to more constants removed in the
test-suite, probably because currently we have to be very lucky to visit
applicable functions in the right order.
Maybe it would make sense to resolve undefs depending on the call graph,
e.g. leaf functions first, but I am not sure how/if that would be doable
in a lightweight fashion.
This test seems broken to me:
(1) branching on undef is UB (I think).
(2) even if it's not UB, what other than 10 would this function return? Literally looking at the single return statements makes this already clear. So if it returns, it has to be 10.
I'll put a patch with IPConstantProp tests improvements up soon and for this one I have looks sth like this:
Let me know what you think.