Changed ifunc resolver for _jr_resolv to use the `static const` initialiser in the new macro-based constant expression xsubi endianess resolver. The ifunc resolver always had resolved the correct function at compile-time and consists of a single `jmp` into it, this doesn"t change anything but make it consistent with the constant expression resolver"s methods (which do matter for that one.)
This behaviour is reversible. See `src/rng/crand.c" for the preprocessor flag based options (although this one should make no different in codegen at all.)
Fortune for rngxx's current commit: Future small blessing − 末小吉
// This being `static const` initialised makes this function be seen as a proper constant expression. Nothing is leaked on to the stack of the caller and the function is replaced with a single `lea`.
// The ifunc `_jr_st_resolv()` is essentially (almost) the same as a symbol-aliased constexpr function.
// The ifunc `_jr_st_resolv()` is essentially (almost) the same as a symbol-aliased constexpr function.
// Ain't that neat?
// Ain't that neat?
#ifdef _RNGXX_JR_RESOLV_IFUNC_OLD_STACKDYN_CHECK
// The old, dynamic stack alloc of the struct, instead of putting it in global r/o data
structjr_statechk={0};
structjr_statechk={0};
chk.st.xsubh=JR_MAX;
chk.st.xsubl=JR_MAX;
#else
// The new, static const alloc of the struct, puts the value in at compile-time. Better optimisation opportunities.
// NOTE: Both stratergies make the ifunc resolve its target at compile-time, there is no difference in this ifunc resolver between the two. However, in `_resv_is_high()`, the old (this) stratergy prevents it being recognised as a constant-expression and stack-allocates the useless memory in the function's (macro-expanded) caller. Causing a spill of useless instructions that the new method changes to one `lea'.