Preserve IL for CoreCLR interpreter fallback on Apple mobile

[Copilot]

Apple mobile composite ReadyToRun publishing could strip IL later required by the CoreCLR interpreter when compiled code is rejected or unavailable in a custom load context.

• Stripping policy

  • Preserve IL for methods with per-method instruction-set support fixups.
  • Retain component IL on Apple mobile targets where interpreter fallback remains possible.

• Coverage

  • Add focused ReadyToRun coverage for opportunistic instruction sets and Apple mobile publishing.
  • Remove the temporary project-level IL-stripping opt-outs.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[kotlarmilos]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Apple mobile composite ReadyToRun publishing could strip IL later required by the CoreCLR interpreter when compiled code is rejected

This sounds like a bug in how we produce the R2R images for use with interpreter. The instruction set should be fixed in this case, and we should never reject the native code. If the actual machine supports more instruction set extensions that the fixed set, we should ignore them.

[kotlarmilos]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 13/13 changed files
• Comments generated: 1

[kotlarmilos]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

Comments suppressed due to low confidence (2)

src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs:977

• EagerInstructionSetSupportHasNoUnsupportedEntries claims to validate the global eager baseline Check_InstructionSetSupport fixup, but it currently scans all import sections (including non-eager/method-level sections). This can produce false failures if any per-method Check_InstructionSetSupport signatures contain '-' entries.

Filter to eager import sections (ReadyToRunImportSectionFlags.Eager) to match the method's stated intent.

        foreach (ReadyToRunImportSection section in reader.ImportSections)
        {
            if (section.Entries is null)
                continue;

            foreach (ReadyToRunImportSection.ImportSectionEntry entry in section.Entries)
            {
                if (entry.Signature is not null && entry.Signature.FixupKind == ReadyToRunFixupKind.Check_InstructionSetSupport)
                    signatures.Add(entry.Signature.ToString(options));
            }
        }

src/libraries/System.Reflection.Metadata/tests/Metadata/Decoding/SignatureDecoderTests.cs:266

• The stripped-IL detection uses raw opcode bytes (0x2A and 0xFE 0x24) without explaining what 0xFE 0x24 represents. Adding a brief comment (and a named constant for 0x2A) would make it clearer that this matches the crossgen2 IL-stripping sentinel (CopiedMethodILNode.s_minimalILBody).

                var il = body.GetILBytes();
                bool isStripped =
                    (il?.Length == 1 && il[0] == 0x2A) ||
                    (il?.Length == 2 && il[0] == 0xFE && il[1] == 0x24);
                if (!isStripped)

• Files reviewed: 13/13 changed files
• Comments generated: 0 new

[jkotas]

since a failing eager fixup is a fatal startup error with no JIT fallback (see ToInstructionSetSupportString

If we have no JIT fallback, we want to make sure that everything both the AOT compiler and the runtime are configured to use the same fixed instruction set so that the instruction support eager fixup would never fail.

It is fine to delete the instruction support eager fixup as an optimization.

'Targets that cannot generate code at runtime must not encode "must be absent" assertions' reasoning looks suspect to me. It says "oh, this was failing at runtime so have stopped generating to make the failure go away". Is this just hiding a bug? Is this change still necessary to fix the issues that this PR is fixing?

[kotlarmilos]

On Apple arm64 the baseline signature emits "must be absent" assertions for the opportunistic instruction sets that fall outside the fixed baseline. GetFixedInstructionSetSupport widens that absent set to the full complement of the fixed baseline, and the device hardware actually provides many of those sets, so the eager Check_InstructionSetSupport fixup fails at load and disables all ReadyToRun code. With IL stripped and no JIT there is no fallback, so startup crashes.

Crossgen2 already fixes the required set through Helpers.GetFixedInstructionSetSupport, and the device has all of it, so the required half already agrees and the check passes. The excluded set is the half that pinning cannot fix. It says the CPU must not have the optional features the code skipped. Apple hardware does have those features, so this check always fails on that hardware. A failed fixup is fatal without a JIT. That is why aligning the fixed set does not prevent the failure.

On a JIT target a mismatch rejects the baseline method and the JIT recompiles for the richer hardware. Without a JIT that path does not exist, so their only effect is to reject valid fixed-baseline code and crash.

I kept the "must be present" half as an invariant check, since those sets are guaranteed present on these targets. I can drop the whole eager fixup for no-JIT targets instead if you prefer that.

[Copilot]

Copilot's findings

• Files reviewed: 13/13 changed files
• Comments generated: 0 new

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[jkotas]

LGTM. Thank you!

[kotlarmilos]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).