Disable PerfMap generation for Apple mobile platforms

[kotlarmilos]

Description

After #121187 Crossgen2 determines cross-compilation targets by reading Crossgen2Tool.GetMetadata(MetadataKeys.TargetOS). This code path triggers PerfMapWriter, which currentl doesn't support iOS targets. This PR disables PerfMap generation for Apple mobile platforms.

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[kotlarmilos]

/cc: @jkoritzinsky Please let me know if this is good approach

[Copilot]

Pull Request Overview

This PR adds support for Apple platform variants to the PerfMap writer by mapping additional Darwin-based operating systems (MacCatalyst, iOS, iOSSimulator, tvOS, tvOSSimulator) to the existing OSX PerfMapOSToken.

Key Changes

• Maps five additional Apple platform variants to PerfMapOSToken.OSX in the switch expression

Comments suppressed due to low confidence (1)

src/coreclr/tools/aot/ILCompiler.Diagnostics/PerfMapWriter.cs:126

• The switch expression is now missing a case for TargetOS.WebAssembly which exists in the TargetOS enum (defined in src/coreclr/tools/Common/TypeSystem/Common/TargetDetails.cs). This will cause a NotImplementedException at runtime when WebAssembly is used as the target OS. Add a case for TargetOS.WebAssembly with an appropriate PerfMapOSToken mapping, or add test coverage to ensure all TargetOS values are handled.

 PerfMapOSToken osToken = details.OperatingSystem switch
{
TargetOS.Unknown => PerfMapOSToken.Unknown,
TargetOS.Windows => PerfMapOSToken.Windows,
TargetOS.Linux => PerfMapOSToken.Linux,
TargetOS.OSX => PerfMapOSToken.OSX,
TargetOS.MacCatalyst => PerfMapOSToken.OSX,
TargetOS.iOS => PerfMapOSToken.OSX,
TargetOS.iOSSimulator => PerfMapOSToken.OSX,
TargetOS.tvOS => PerfMapOSToken.OSX,
TargetOS.tvOSSimulator => PerfMapOSToken.OSX,
TargetOS.FreeBSD => PerfMapOSToken.FreeBSD,
TargetOS.NetBSD => PerfMapOSToken.NetBSD,
TargetOS.SunOS => PerfMapOSToken.SunOS,
_ => throw new NotImplementedException(details.OperatingSystem.ToString())
};

[am11]

Shall we make

runtime/src/coreclr/tools/Common/TypeSystem/Common/TargetDetails.cs

Line 12 in b22d55a

publicenumTargetOS

match

runtime/src/coreclr/tools/aot/ILCompiler.Diagnostics/ReadyToRunDiagnosticsConstants.cs

Line 26 in 98f204b

publicenumPerfMapOSToken:uint

or maybe dedup them if possible?

[jkoritzinsky]

The PerfMap constants are part of the PerfMap format, so any changes would require versioning the format, which isn't worth doing for this case (especially as this format doesn't really make sense in this scenario)

[jkotas]

especially as this format doesn't really make sense in this scenario

Should the right fix be to disable perfmap generation in these scenarios instead then?

[jkoritzinsky]

The right fix would be to disable generation on the consumer side (ie don't pass the flag to emit PerfMaps).

Then we could block passing the flag to emit them for these platforms.

The iOS perf tests for CoreCLR aren't well configured at the moment though if they're hitting this. They're requesting ReadyToRun image generation even though it doesn't work as-is.

[jkotas]

The right fix would be to disable generation on the consumer side (ie don't pass the flag to emit PerfMaps).

@kotlarmilos Can we do that instead this change?

[am11]

PR title can be now changed to Disable PerfMap generation for Apple mobile platforms.

[am11]

@jkoritzinsky,, can we dedup this targets with https://github.com/dotnet/sdk/blob/7538a89c176527c27767a85bdfe0afacef9edeb3/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.CrossGen.targets? Ideally there should be a single source of truth (like @ViktorHofer did for RID graph #92211).

[kotlarmilos]

I assume these changes should be ported to the SDK repo (if not dedup-ed)

[am11]

Yup, they are identical https://www.diffchecker.com/8FCIR0Ag/.

[kotlarmilos]

@jkoritzinsky Should this be upstreamed to the SDK, or is there a way to deduplicate it?

[akoeplinger]

@kotlarmilos note that if you upstream this then you can't use TargetOS since that property is only set in our build.

[akoeplinger]

I do agree we should upstream this though, using TargetPlatformIdentifier, and set the PublishReadyToRunEmitSymbols in our build to false for Apple mobile

[kotlarmilos]

dotnet/sdk#51545

[kotlarmilos]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[kotlarmilos]

/ba-g Android queue timeouts dotnet/dnceng#3008