global variable woe

[aviatesk]

There're mainly two big problems around how JET treats global variabels

1. propagate of non-constant global variables

I thought we can safely propagate the type of (non constant) global variable if we invalidate all the code cache that uses it upon its update (the force_invalidate! logic), but it was wrong.
This is just because we can't invalidate code cache if the update happens within the lineage frames of the current frame. Consider the following example:

var = '1'

function foo(v)
    rand(Bool) && setter!(v)
    sin(var) # <= var::Union{Char,Int} ?
end
setter!(v) = global var = v

foo(10)

Now we need to annotate var as Union{Char,Int}, but this annotation is actually very hard (or even impossible, with the existence of the widening heuristics) to be done in general case (while this particular example is very simple, setter! can happen in a deeply nested conditioned callee).

I guess this is why Julia's native compiler doesn't do what I had done for JET, and now I think I need to throw away the logic in JET as well; JET will just propagate Any for non-constant global variables.
Of course this will make JET's profiling less accurate, but it's consistent with Julia's JIT at least, and I feel we want to have performance-warnings for this instead.

2. control flows in toplevel frames

Well, as for toplevel frames, I rather want to keep VirtualGlobalVarible logic. Toplevel call signatures are really important for JET's profiling process, because they're "starting points" of our analysis.
Assuming assignments of global variables only happen in toplevel frames, I would like to improve the accuracy of our virtual global variable assignments.

Consider the following example:

v = rand(Int)
if rand(Bool)
    v = '1'
end

sin(v)

At sin(v), v should be annotated as v::Union{Int,Char} (and thus union-split NoMethodError should be reported), while JET now interprets toplevel code by per-basic-block basis, and only has really naive assignment logic, and so it's annotated as v::Char, which should be fixed anyway.