Linker conditionals for WASM System.Private.CoreLib

[vargaz]

Here is a list of possible linker conditionals which a linker tool can use to optimize corelib for a particular platform:

• The IsSupported methods in the various classes under System.Runtime.Intrinsics
• System.Numerics.Vector::get_IsHardwareAccelerated ()
• System.Globalization.GlobalizationMode::GetInvariantSwitchValue ()
• System.Globalization.GlobalizationMode::get_Invariant()
• System.Environment::get_ProcessorCount()
• System.Environment::get_IsSingleProcessor()
• SR::UsingResourceKeys () [In System.Console].

[vargaz]

Related linker issues:

• Would be nice to have a version of the System.Console PAL for mobile systems which would allow only simple output, the current Console.Unix version contains a lot of functionality which is not available on the stdout implementations on mobile.
• The 'type is TypeBuilder' pattern in corelib code prevents TypeBuilder from being linked out, a linker friendly approach would be adding a IsTypeBuilder () virtual method in a base type like Type and overriding it in TypeBuilder.

[jkotas]

System.Console PAL for mobile systems which would allow only simple output

Agree. I believe a separate build of System.Console for mobile systems would be the best way to handle this.

type is TypeBuilder

This may be rather handled by a more general optimization for never allocated types that would kick in many other places. The linker should be able to see that TypeBuilder is never allocated and short-circuit this condition.

[stephentoub]

Is this only existing properties / parameterless methods?

I'd expect some decent wins to come from things like Environment.GetEnvironmentVaraible being used to check for some well-known value, AppContext switches, etc. If the linker isn't yet capable of that and the resulting dataflow analysis, e.g. a static readonly bool field being set based on those and used as a const, it might be something we should look at adding.

Another would be Debugger.IsAttached. is that already factored in as part of telling the linker to throw away debugging-related code? We have some code paths that only kick in when a debugger is active.

Similarly, EventSource.IsEnabled; do we have switches that would let someone link away an entire EventSource(s) if they don't care about a particular component's logging?

What about encodings? Calendars? Etc?

[marek-safar]

Only static properties and static parameterless methods are supported.

[richlander]

Questions I asked on email that should be shared more broadly.

• What is the scenario where CPU count would be used for linking?
• Is this list thought be complete?

Answers:

• web assembly is the primary scenario for CPU count since it is single threaded / core.
• no this list is not thought to be complete.