This PR fixes a very odd corner case of global dataflow through global variables.

Consider this snippet (which I've also added as a test):

int recursion = (sink(recursion), source());

The IR we generate for this snippet is roughly equivalent to:

void__initialize_recursion() {sink(recursion);  recursion =source();}

where__recursion represents the actual global variable. Since this is anIRFunction just like any otherFunction, it gets an initial SSA definition of the global variables that it reads, and it gets a final SSA use of the global variables that it defines. So for the point-of-view of dataflow the function ends up looking like:

void__initialize_recursion() {  recursion = __initialize_global;// (3)sink(recursion);// (4)  recursion =source();// (1)__final_use(recursion);// (2)}

where__initialize_global represents the initial SSA definition (aInitialGlobalValue node), and__final_use(recursion) represents the final SSA use (aFinalGlobalValue node).

And now global variable dataflow does its things and this happens:

1. A write torecursion at// (1) flows to the final SSA use at// (2)
2. A jump step causes flow from// (2) to the global dataflow node (aGlobalLikeVariableNode) forrecursion
3. Another jump step from the global dataflow node forrecursion to the initial SSA definition forrecursion at// (3)
4. A normal flow step from// (3) to the use at// (4).

But clearly we should not have flow in this case! So this PR fixes the FP by removing theInitialGlobalValue node for some global variablev at the entry for theIRFunction that initializesv.

I don't think this will ever happen on any real codebase. But since it was so easy to fix we might as well get this fix in 😄