[no merge] Introduce a new attribute indicating a method uses StackCrawlMark

[jamesqo]

Currently we assume a method has a StackCrawlMark local var if it is in mscorlib and marked NoInlining. This can lead to potential pessimizations when we want to use NoInlining for other purposes (namely, performance), e.g. #7007, #6890.

This PR adds a new System.Runtime.CompilerServices.UsesStackCrawlMarkAttribute, and marks methods that use StackCrawlMark w/ that instead of NoInlining. (relevant commit) To be honest, I am not quite sure I know what I'm doing, I basically copy-and-pasted the logic to specially recognize NativeCallableAttribute and just replaced it with UsesStackCrawlMark.

@jkotas is that all that needs to be done?

[jkotas]

@jkotas is that all that needs to be done?

There are likely tweaks needed in more places to make it actually work (the CI tests are failing...).

Also, the JIT throughput impact should be checked. The custom attribute looks in JIT-EE interface tend to have measurable impact on JIT throughput.

cc @dotnet/jit-contrib

[jamesqo]

(the CI tests are failing...)

Hm, I just noticed that I have the attribute defined in the macro as System.Threading._ when it should be System.Runtime.CompilerServices._. I'll try changing that and see if they pass. (edit: actually it is Runtime.CompilerServices, I had already fixed it)

The custom attribute looks in JIT-EE interface tend to have measurable impact on JIT throughput.

This is only being checked for mscorlib though (lookup is preceded by IsSystem() check), which is precompiled.

[pgavlin]

@jamesqo: even though this is only being checked for the core library, it may impact the time it takes for the JIT to precompile the core library (which is a metric that we track pretty closely). I'll take a look and see if there's any significant throughput hit here.

[jkotas]

@pgavlin I believe it impacts all code - when it is calling methods in corelib.

[pgavlin]

@jkotas: yes, you're correct. Serves me for not looking closely enough at the context for the method that changed. :)

[jamesqo]

If custom attributes have too much overhead, then maybe we could have contradictory flag values that are unlikely to show up for actual uses, e.g. we could mark StackCrawlMark methods w/ AggressiveInlining | NoInlining.

[danmoseley]

@jamesqo are you still working on this PR?

[jamesqo]

@danmosemsft I can move this to an issue for now. Sorry, I seem to be forgetting about a lot of my coreclr PRs (in particular ones that change the C++ side of things, since the runtime takes an hour to build).