Atomically order specsigflags, specptr, and invoke

[pchintalapudi]

These atomics depend on the following rules:

On the write side:

1. Once set, specptr may never change to an invalid value (i.e. it must always be callable as a specptr)
2. specsigflags & 0b1 may only be set if the current thread just set specptr and the previous value of specptr was NULL
3. Once set, invokeptr may never change to an invalid value (i.e. it must always be callable as an invokeptr)
4. specsigflags & 0b10 must be set after the current thread sets both invokeptr and specptr

On the read side:

1. When planning to read from specsigflags or specptr, invokeptr should be loaded with at least acquire semantics
2. When reading from specsigflags or specptr for non-calling purposes, if specptr is non-null, then it is necessary to busy-loop on specsigflags & 0b10 until that bit is set
3. invokeptr must be reloaded (relaxed) after the previous busyloop

The reasoning behind this set of changes is that we want to support multiple threads setting specptr/invokeptr/specsig to potentially different values, and we don't want to end up in a situation where the codeinst transitions from being valid to be called to invalid to be called. This motivates the once-set restrictions. However, we also want to support potential future upgrading of invokeptr/specptr (e.g. to transition from interpreted to compiled, or compiled at low optimization to compiled at high optimization), which motivates being able to override specptr and invokeptr as long as those values are equivalently callable.

Invokeptr must be reloaded after checking for 0b10 in specsigflags due to the case of the original load returning an invokeptr that does not rely on specptr (for interpretation), but then another thread sets specptr. In this case, we want to grab the updated invokeptr which we know is definitely written after specsigflags & 0b10 is set.

[vtjnash]

LGTM (reviewed in-person)

Should we also make this a little more accurate (requiring forward progress of each iteration):

diff --git a/src/gf.c b/src/gf.c
index df50b42216..b8223efb7c 100644
--- a/src/gf.c
+++ b/src/gf.c
@@ -2199,10 +2199,11 @@ jl_value_t *jl_fptr_const_return(jl_value_t *f, jl_value_t **args, uint32_t narg
 
 jl_value_t *jl_fptr_args(jl_value_t *f, jl_value_t **args, uint32_t nargs, jl_code_instance_t *m)
 {
+    jl_fptr_args_t invoke = jl_atomic_load_relaxed(&m->specptr.fptr1);
     while (1) {
-        jl_fptr_args_t invoke = jl_atomic_load_relaxed(&m->specptr.fptr1);
         if (invoke)
             return invoke(f, args, nargs);
+        invoke = jl_atomic_load_acquire(&m->specptr.fptr1);
     }
 }

[pchintalapudi]

@maleadt does GPUCompiler use any of codeinst->(invoke, specptr, isspecsig)? If so, we'll need to update those parts of GPUCompiler to conform to these restrictions.

[maleadt]

@maleadt does GPUCompiler use any of codeinst->(invoke, specptr, isspecsig)?

No, we never use what's been compiled by the JIT, but use aotcompile directly.

[vtjnash]

bump? Looks like this needs a rebase