S.P.Corelib uses the System.Runtime.Versioning.NonVersionableAttribute in select locations to represent code which won't fundamentally change.

In terms of crossgen, code marked with this attribute is always allowed to be inlined into the method being compiled, even across "version bubbles": https://github.com/dotnet/runtime/blob/master/docs/design/features/crossgen2-compilation-structure-enhancements.md#behavior-of-code-that-shares-a-version-bubble

The linker should likewise understand this attribute so it can perform similar optimizations. In particular, this would likely be useful with the Internal.Runtime.CompilerServices.Unsafe class which is effectively contracted to a particular IL sequence and which only exists to workaround limitations in C#: https://source.dot.net/#System.Private.CoreLib/Unsafe.cs,5f348ec84090bc93

There are likewise a handful of other minor usages throughout S.P.Corelib that would ultimately allow better codegen: https://source.dot.net/#System.Private.CoreLib/NonVersionableAttribute.cs,05d4b3f46382a993,references

An example of where this may be beneficial is with Unsafe.SkipInit<T>(out T value). This method is a nop, that is it does nothing and returns. It's only purpose is to bypass C# definite assignment rules and so it gets used in places such as dotnet/runtime#47860, where we need a variable to be in the parent scope but where it only gets initialized under specific conditions (and where initialization may otherwise hurt performance).

If the linker were to inline this, then not only could Unsafe.SkipInit be trimmed but it may lead to the only remaining usage of a type being detected as unused and therefore also trimmable (Vector128<T> in this case).