-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure illink task to trim unreachable platform-specific code #31785
Comments
Related #31712 |
If the build machine has different hardware capabilities than that of consumers', wouldn't it produce unexpected result? For instance, if software fallback is removed by this optimization, and some consumer required it. |
Aren't HWIntrinsics configurable by environment variable before the execution of the runtime? https://github.com/dotnet/runtime/blob/master/src/coreclr/src/jit/jitconfigvalues.h#L223-L245 |
I think this is about e.g. all x64 intrinsics never returning |
I don't believe we currently support this for the R2R code. We would have to determine if it is appropriate to support for AOT code in general. |
My understanding is that this issue is calling for us to add configuration such as the following to our ILLink invokation.
And similar for each case @jkotas mentions above, and maintain a different set of values for each architecture and platform we build for. Do we really think this is the right way to control this? Can we instead do so with metadata on the methods? That way anyone running the linker can benefit with a simple flag (eg: --honor-platform-specific-metadata-for-platform:plat-arch or something) |
What metadata would you add the the method? The configuration for each RID which will be used during libraries build will be different and for some platforms (e.g. webassembly) much longer than what Jan listed in initial set. Perhaps a better example would be to use We could also embed such configuration file into System.Private.CoreLib for linker to use the data also when linking user apps for specific RID. |
I was thinking something like
or
I think it makes the most sense for this sort of information to be maintained parallel to the API which implements it (ideally in the same source file). Also we should have tests that make sure that whatever information is checked in agrees with the actual API behavior on that platform. |
Some of the metadata, such as hardware intrinsic |
It still might be useful, for example for platforms where the intrinsics set is restricted (e.g. wasm)
How would that work for e.g. Note, the xml file/syntax will still be used to let users control features like System.Globalization.Invariant |
I've opened #37615 which covers:
The original proposed constants above that I don't know how to support with the ILLinker are:
The OSPlatform API is tricky because you always pass a parameter into the method, and I don't think the ILLinker supports trimming branches on methods that have parameters: |
Should this also cover |
I don't think it should. It's rare to see this code used in conditional comparison |
Ported the settings from https://github.com/mono/mono/blob/eaa32d13659f0a6b6b5e62ddb49af68b1f9efb6c/sdks/wasm/src/linker-subs.xml and split them out as appropriate to reduce duplication across the different platform builds. Contributes to dotnet#31785
* Add ILLink.Substitutions.xml files for System.Private.CoreLib. Ported the settings from https://github.com/mono/mono/blob/eaa32d13659f0a6b6b5e62ddb49af68b1f9efb6c/sdks/wasm/src/linker-subs.xml and split them out as appropriate to reduce duplication across the different platform builds. Contributes to #31785 * Remove all Platforms other than wasm to workaround linker bug. See dotnet/linker#1260
@eerhardt assigning you. Is the tracking work already done or is there something else necessary to be done for 5.0? |
It is tracking filling out this TODO: runtime/src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems Line 20 in c652058
Which is blocked on the underlying linker issue. |
This was addressed in #42578. |
IL linker is capable of constant propagation and dead code removal (see dotnet/linker#848).
We should configure linking for the runtime package to eliminate platform-specific unreachable code that is under conditions like:
The text was updated successfully, but these errors were encountered: