Context: #90711 (comment) (the whole thread)

Some EE apis aren't invariant by design (invariant as in - always return the same value for the same arguments) and JIT has to be careful with them (for the rest, we can make SPMI assert in case if they turn out to be non-invariant). The task is to mark them with some special marker-macro or comment in ThunkInput.txt and generate asserts for SPMI (in case if we make methodcontext.cpp at least partially auto-generated for trivial cases) and, also, revise all uses for potential problems. From a quick look these APIs are not invariant:

• uint32_t getMethodAttribs(CORINFO_METHOD_HANDLE ftn);
• CorInfoInline canInline(CORINFO_METHOD_HANDLE callerHnd, CORINFO_METHOD_HANDLE calleeHnd);
• uint32_t getClassAttribs(CORINFO_CLASS_HANDLE cls)
• CorInfoInitClassResult initClass(CORINFO_FIELD_HANDLE field, CORINFO_METHOD_HANDLE method, CORINFO_CONTEXT_HANDLE context)
• bool getStaticFieldContent(CORINFO_FIELD_HANDLE field, uint8_t *buffer, int bufferSize, int valueOffset, bool ignoreMovableObjects);
• CORINFO_CLASS_HANDLE getStaticFieldCurrentClass(CORINFO_FIELD_HANDLE field, BoolStar pIsSpeculative);
• void* getHelperFtn (CorInfoHelpFunc ftnNum, void **ppIndirection);
• void getFunctionEntryPoint(CORINFO_METHOD_HANDLE ftn, CORINFO_CONST_LOOKUP* pResult, CORINFO_ACCESS_FLAGS accessFlags);
• void getFunctionFixedEntryPoint(CORINFO_METHOD_HANDLE ftn, bool isUnsafeFunctionPointer, CORINFO_CONST_LOOKUP * pResult);

last two should be still invariant as of today, but they might start using the same trick as getHelperFtn (return direct address in case if destination function already reached the final tier).