Fix how `System.Linq.Expressions.dll` is supported on iOS-like platforms

[ivanpovazan]

Description

There is a difference in how System.Linq.Expressions.dll is built for iOS-like and other desktop/mobile platforms, which is observable here:

• runtime/eng/illink.targets

  Line 226 in 2aa0c9b

  <ILLinkArgs Condition="'$(ILLinkDisableIPConstProp)' == 'true'">$(ILLinkArgs) --disable-opt ipconstprop</ILLinkArgs>

• runtime/src/libraries/System.Linq.Expressions/src/System.Linq.Expressions.csproj

  Line 19 in 2aa0c9b

  <ILLinkDisableIPConstProp Condition="'$(TargetPlatformIdentifier)' != 'ios' and '$(TargetPlatformIdentifier)' != 'tvos' and '$(TargetPlatformIdentifier)' != 'maccatalyst'">true</ILLinkDisableIPConstProp>

• Up until now this difference was not noticeable, however with enabling support for iOS-like platforms with NativeAOT we started experiencing:

  1. Failing Linq.Expressions tests with NativeAOT on iOS-like platforms: https://github.com/dotnet/runtime/pull/87260/files#diff-4422ce02e9237f4f8e6021526506f87216778e497b33ce676872c1f70e1483c2R54
  2. System.Func`3 delegate instances take up to 18% of accountable size of a MAUI iOS app with NativeAOT (the cause explained bellow)

• Additionally, there were several issues reported against MonoAOT, struggling with Linq.Expressions.Interpreter reported here:

  • Crash on using Expression.Compile() in a release mode (iOS). #69410
  • MAUI iOS Release mode crash: Attempting to JIT compile method '(wrapper delegate-invoke) bool <Module>:invoke_callvirt_bool_SafeHandleZeroOrMinusOneIsInvalid (Microsoft.Win32.SafeHandles.SafeHandleZeroOrMinusOneIsInvalid)' while running in aot-only mode  #83212

Explanation

NativeAOT

The issue was called out by @MichalStrehovsky noting that codepaths in Linq.Expressions library controlled by:

• CanCompileToIL
• CanEmitObjectArrayDelegate
• CanCreateArbitraryDelegates

are not AOT friendly (reported here).

For desktop platforms, NativeAOT fixes this by:

• disabling constant propagation when Linq.Expressions.dll
  • this prevents above-listed control variables to get trimmed during the build
• introducing feature switches that will substitute the control variables and trim AOT-unfriendly code and provide full AOT experience
  • achieved through

    runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

    Lines 271 to 273 in 2aa0c9b

    	<IlcArg Include="--feature:System.Linq.Expressions.CanCompileToIL=false" />
    	<IlcArg Include="--feature:System.Linq.Expressions.CanEmitObjectArrayDelegate=false" />
    	<IlcArg Include="--feature:System.Linq.Expressions.CanCreateArbitraryDelegates=false" />

When it comes to iOS-like platforms, above is not true. When Linq.Expressions library is built, constant propagation is enabled and control variables get removed during the library build.
This further causes above-listed NativeAOT feature switches not to have any effect (fail to trim during app build), causing the AOT compilation to follow unsupported code paths which fail at runtime.
Examples:

• Build warnings:

  name(7,8): warning IL2009: System.Linq.Expressions: Could not find method 'System.Boolean get_CanEmitObjectArrayDelegate()' on type 'System.Dynamic.Utils.DelegateHelpers'. [/Users/ivan/repos/runtime-mono-iOS/src/mono/sample/    iOS-NativeAOT/Program.csproj]
  name(10,8): warning IL2009: System.Linq.Expressions: Could not find method 'System.Boolean get_CanCreateArbitraryDelegates()' on type 'System.Linq.Expressions.Interpreter.CallInstruction'. [/Users/ivan/repos/runtime-mono-iOS/src/    mono/sample/iOS-NativeAOT/Program.csproj]
  

• Test crash

  runtime/src/tests/nativeaot/SmokeTests/UnitTests/Delegates.cs

  Line 54 in 7b7d56f

  TestLinqExpressions.Run();

  on a iOS device:

  2023-06-22 12:51:24.569126+0200 HelloiOS[12307:4919002] Testing LINQ Expressions...
  2023-06-22 12:51:24.705363+0200 HelloiOS[12307:4918969] Unhandled Exception: System.PlatformNotSupportedException: Dynamic code generation is not supported on this platform.
     at System.Reflection.Emit.ReflectionEmitThrower.ThrowPlatformNotSupportedException() + 0x38
     at System.Reflection.Emit.DynamicMethod..ctor(String, Type, Type[]) + 0x2c
     at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegateRefEmit(Type, Func`2) + 0x450
     at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegate(Type, Func`2) + 0x38
     at System.Linq.Expressions.Interpreter.LightLambda.MakeDelegate(Type) + 0xcc
     at System.Linq.Expressions.Interpreter.LightDelegateCreator.CreateDelegate(IStrongBox[]) + 0x74
     at System.Linq.Expressions.Interpreter.LightDelegateCreator.CreateDelegate() + 0x1c
     at System.Linq.Expressions.Expression`1.Compile() + 0x74
     at TestLinqExpressions.Run() + 0x140
  

MonoAOT

As for MonoAOT is concerned, there were several issues reported against the Linq.Expressions.Interpreter support. Some issues were fixed, some are still open, but in general following unfriendly AOT codepaths also hurts Mono.
Example:

• Following the code path:

  • runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.cs

    Line 35 in 2e764d6

    public static CallInstruction Create(MethodInfo info, ParameterInfo[] parameters)

  • runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.cs

    Line 86 in 2e764d6

    res = FastCreate(info, parameters);

  • runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.Generated.cs

    Lines 44 to 154 in 2e764d6

    	switch (t.GetTypeCode())
    	{
    	case TypeCode.Object:
    	{
    	if (t != typeof(object) && (IndexIsNotReturnType(0, target, pi) || t.IsValueType))
    	{
    	// if we're on the return type relaxed delegates makes it ok to use object
    	goto default;
    	}
    	return FastCreate<Object>(target, pi);
    	}
    	case TypeCode.Int16: return FastCreate<Int16>(target, pi);
    	case TypeCode.Int32: return FastCreate<Int32>(target, pi);
    	case TypeCode.Int64: return FastCreate<Int64>(target, pi);
    	case TypeCode.Boolean: return FastCreate<Boolean>(target, pi);
    	case TypeCode.Char: return FastCreate<Char>(target, pi);
    	case TypeCode.Byte: return FastCreate<Byte>(target, pi);
    	case TypeCode.Decimal: return FastCreate<Decimal>(target, pi);
    	case TypeCode.DateTime: return FastCreate<DateTime>(target, pi);
    	case TypeCode.Double: return FastCreate<Double>(target, pi);
    	case TypeCode.Single: return FastCreate<Single>(target, pi);
    	case TypeCode.UInt16: return FastCreate<UInt16>(target, pi);
    	case TypeCode.UInt32: return FastCreate<UInt32>(target, pi);
    	case TypeCode.UInt64: return FastCreate<UInt64>(target, pi);
    	case TypeCode.String: return FastCreate<String>(target, pi);
    	case TypeCode.SByte: return FastCreate<SByte>(target, pi);
    	default: return SlowCreate(target, pi);
    	}
    	}
    	private static CallInstruction FastCreate<T0>(MethodInfo target, ParameterInfo[] pi)
    	{
    	Type t = TryGetParameterOrReturnType(target, pi, 1);
    	if (t == null)
    	{
    	if (target.ReturnType == typeof(void))
    	{
    	return new ActionCallInstruction<T0>(target);
    	}
    	return new FuncCallInstruction<T0>(target);
    	}
    	if (t.IsEnum) return SlowCreate(target, pi);
    	switch (t.GetTypeCode())
    	{
    	case TypeCode.Object:
    	{
    	if (t != typeof(object) && (IndexIsNotReturnType(1, target, pi) || t.IsValueType))
    	{
    	// if we're on the return type relaxed delegates makes it ok to use object
    	goto default;
    	}
    	return FastCreate<T0, Object>(target, pi);
    	}
    	case TypeCode.Int16: return FastCreate<T0, Int16>(target, pi);
    	case TypeCode.Int32: return FastCreate<T0, Int32>(target, pi);
    	case TypeCode.Int64: return FastCreate<T0, Int64>(target, pi);
    	case TypeCode.Boolean: return FastCreate<T0, Boolean>(target, pi);
    	case TypeCode.Char: return FastCreate<T0, Char>(target, pi);
    	case TypeCode.Byte: return FastCreate<T0, Byte>(target, pi);
    	case TypeCode.Decimal: return FastCreate<T0, Decimal>(target, pi);
    	case TypeCode.DateTime: return FastCreate<T0, DateTime>(target, pi);
    	case TypeCode.Double: return FastCreate<T0, Double>(target, pi);
    	case TypeCode.Single: return FastCreate<T0, Single>(target, pi);
    	case TypeCode.UInt16: return FastCreate<T0, UInt16>(target, pi);
    	case TypeCode.UInt32: return FastCreate<T0, UInt32>(target, pi);
    	case TypeCode.UInt64: return FastCreate<T0, UInt64>(target, pi);
    	case TypeCode.String: return FastCreate<T0, String>(target, pi);
    	case TypeCode.SByte: return FastCreate<T0, SByte>(target, pi);
    	default: return SlowCreate(target, pi);
    	}
    	}
    	private static CallInstruction FastCreate<T0, T1>(MethodInfo target, ParameterInfo[] pi)
    	{
    	Type t = TryGetParameterOrReturnType(target, pi, 2);
    	if (t == null)
    	{
    	if (target.ReturnType == typeof(void))
    	{
    	return new ActionCallInstruction<T0, T1>(target);
    	}
    	return new FuncCallInstruction<T0, T1>(target);
    	}
    	if (t.IsEnum) return SlowCreate(target, pi);
    	switch (t.GetTypeCode())
    	{
    	case TypeCode.Object:
    	{
    	Debug.Assert(pi.Length == 2);
    	if (t.IsValueType) goto default;
    	return new FuncCallInstruction<T0, T1, Object>(target);
    	}
    	case TypeCode.Int16: return new FuncCallInstruction<T0, T1, Int16>(target);
    	case TypeCode.Int32: return new FuncCallInstruction<T0, T1, Int32>(target);
    	case TypeCode.Int64: return new FuncCallInstruction<T0, T1, Int64>(target);
    	case TypeCode.Boolean: return new FuncCallInstruction<T0, T1, Boolean>(target);
    	case TypeCode.Char: return new FuncCallInstruction<T0, T1, Char>(target);
    	case TypeCode.Byte: return new FuncCallInstruction<T0, T1, Byte>(target);
    	case TypeCode.Decimal: return new FuncCallInstruction<T0, T1, Decimal>(target);
    	case TypeCode.DateTime: return new FuncCallInstruction<T0, T1, DateTime>(target);
    	case TypeCode.Double: return new FuncCallInstruction<T0, T1, Double>(target);
    	case TypeCode.Single: return new FuncCallInstruction<T0, T1, Single>(target);
    	case TypeCode.UInt16: return new FuncCallInstruction<T0, T1, UInt16>(target);
    	case TypeCode.UInt32: return new FuncCallInstruction<T0, T1, UInt32>(target);
    	case TypeCode.UInt64: return new FuncCallInstruction<T0, T1, UInt64>(target);
    	case TypeCode.String: return new FuncCallInstruction<T0, T1, String>(target);
    	case TypeCode.SByte: return new FuncCallInstruction<T0, T1, SByte>(target);
    	default: return SlowCreate(target, pi);

    (notice the use of generics over value types)

includes generating code for a lot of generic delegates and Mono tries its best to support these, but at what cost?

It is true that choosing delegates to implement fast invocation of methods should have better performance, but in case with Mono and delegates over value types, the compiler will generate GSHAREDVT methods (generic sharing for value types) which are actually quite slow.
On the other hand, NativeAOT does not have generic sharing for value types and generates instead all possible variations (causing the problem reported above 2) with a template MAUI app)

Risk assessment

Pros

• Reducing the gap in behaviour between MonoAOT and NativeAOT
• Better support for Linq.Expressions with Mono
• Enabling NativeAOT tests for Linq.Expressions on iOS-like platforms
• Estimated code size improvements:
  • NativeAOT ~30% smaller MAUI template app
  • MonoAOT ~2.5% smaller MAUI template app (the difference is way smaller compared to NativeAOT as Mono generates GSHAREDVT for fast invocation)
• Better user experience:
  • due to reported Attempting to JIT compile method (wrapper delegate-invoke) users had to enable mono interpreter in their projects (UseInterpreter=true) to cover-up for missing methods during runtime, which also affects the application size

Cons

• Regression in performance (to be confirmed)
  • This has to be measured and evaluated especially because MonoAOT uses GSHAREDVT in these cases

Proposal

Here is the list of tasks which should resolve all the reported issues around Linq.Expressions on iOS-like platforms

• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759
• Respect IsDynamicCodeSupported in more places in Linq.Expressions #88539
• [mono] Add conditional substitution for IsDynamicCodeSupported when targeting ios-like platforms #86971
• [libs][iOS] Unify System.Linq.Expression.dll build for all platforms #88723
• Set the IsDynamicCodeSupported feature to false when using FullAOT macios#18340
• [NativeAOT] Enable System.Linq.Expressions tests on iOS-like platforms #89168
• [NativeAOT] Refactor System.Linq.Expressions private feature switches #89171

---

Thanks to @MichalStrehovsky @vargaz @rolfbjarne for helping to identify these issues.

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

Issue Details

---

Description

There is a difference in how Linq.Expressions.dll is built for iOS-like and other desktop/mobile platforms, which is observable here:

• runtime/eng/illink.targets

  Line 226 in 2aa0c9b

  <ILLinkArgs Condition="'$(ILLinkDisableIPConstProp)' == 'true'">$(ILLinkArgs) --disable-opt ipconstprop</ILLinkArgs>

• runtime/src/libraries/System.Linq.Expressions/src/System.Linq.Expressions.csproj

  Line 19 in 2aa0c9b

  <ILLinkDisableIPConstProp Condition="'$(TargetPlatformIdentifier)' != 'ios' and '$(TargetPlatformIdentifier)' != 'tvos' and '$(TargetPlatformIdentifier)' != 'maccatalyst'">true</ILLinkDisableIPConstProp>

• Up until now this difference was not noticeable, however with enabling support for iOS-like platforms with NativeAOT we started experiencing:

  1. Failing Linq.Expressions tests with NativeAOT on iOS-like platforms: https://github.com/dotnet/runtime/pull/87260/files#diff-4422ce02e9237f4f8e6021526506f87216778e497b33ce676872c1f70e1483c2R54
  2. System.Func`3 delegate instances take up to 18% of accountable size of a MAUI iOS app with NativeAOT (the cause explained bellow)

• Additionally, there were several issues reported against MonoAOT, struggling with Linq.Expressions.Interpreter reported here:

  • Crash on using Expression.Compile() in a release mode (iOS). #69410
  • MAUI iOS Release mode crash: Attempting to JIT compile method '(wrapper delegate-invoke) bool <Module>:invoke_callvirt_bool_SafeHandleZeroOrMinusOneIsInvalid (Microsoft.Win32.SafeHandles.SafeHandleZeroOrMinusOneIsInvalid)' while running in aot-only mode  #83212

Explanation

NativeAOT

The issue was called out by @MichalStrehovsky noting that codepaths in Linq.Expressions library controlled by:

• CanCompileToIL
• CanEmitObjectArrayDelegate
• CanCreateArbitraryDelegates

are not AOT friendly (reported here).

For desktop platforms, NativeAOT fixes this by:

• disabling constant propagation when Linq.Expressions.dll
  • this prevents above-listed control variables to get trimmed during the build
• introducing feature switches that will substitute the control variables and trim AOT-unfriendly code and provide full AOT experience
  • achieved through

    runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

    Lines 271 to 273 in 2aa0c9b

    	<IlcArg Include="--feature:System.Linq.Expressions.CanCompileToIL=false" />
    	<IlcArg Include="--feature:System.Linq.Expressions.CanEmitObjectArrayDelegate=false" />
    	<IlcArg Include="--feature:System.Linq.Expressions.CanCreateArbitraryDelegates=false" />

When it comes to iOS-like platforms, above is not true. When Linq.Expressions library is built, constant propagation is enabled and control variables get removed during the library build.
This further causes above-listed NativeAOT feature switches not to have any effect (fail to trim during app build), causing the AOT compilation to follow unsupported code paths which fail at runtime.
Examples:

• Build warnings:

  name(7,8): warning IL2009: System.Linq.Expressions: Could not find method 'System.Boolean get_CanEmitObjectArrayDelegate()' on type 'System.Dynamic.Utils.DelegateHelpers'. [/Users/ivan/repos/runtime-mono-iOS/src/mono/sample/    iOS-NativeAOT/Program.csproj]
  name(10,8): warning IL2009: System.Linq.Expressions: Could not find method 'System.Boolean get_CanCreateArbitraryDelegates()' on type 'System.Linq.Expressions.Interpreter.CallInstruction'. [/Users/ivan/repos/runtime-mono-iOS/src/    mono/sample/iOS-NativeAOT/Program.csproj]
  

• Test crash

  runtime/src/tests/nativeaot/SmokeTests/UnitTests/Delegates.cs

  Line 54 in 7b7d56f

  TestLinqExpressions.Run();

  on a iOS device:

  2023-06-22 12:51:24.569126+0200 HelloiOS[12307:4919002] Testing LINQ Expressions...
  2023-06-22 12:51:24.705363+0200 HelloiOS[12307:4918969] Unhandled Exception: System.PlatformNotSupportedException: Dynamic code generation is not supported on this platform.
     at System.Reflection.Emit.ReflectionEmitThrower.ThrowPlatformNotSupportedException() + 0x38
     at System.Reflection.Emit.DynamicMethod..ctor(String, Type, Type[]) + 0x2c
     at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegateRefEmit(Type, Func`2) + 0x450
     at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegate(Type, Func`2) + 0x38
     at System.Linq.Expressions.Interpreter.LightLambda.MakeDelegate(Type) + 0xcc
     at System.Linq.Expressions.Interpreter.LightDelegateCreator.CreateDelegate(IStrongBox[]) + 0x74
     at System.Linq.Expressions.Interpreter.LightDelegateCreator.CreateDelegate() + 0x1c
     at System.Linq.Expressions.Expression`1.Compile() + 0x74
     at TestLinqExpressions.Run() + 0x140
  

MonoAOT

As for MonoAOT is concerned, there were several issues reported against the Linq.Expressions.Interpreter support. Some issues were fixed, some are still open, but in general following unfriendly AOT codepaths also hurts Mono.
Example:

• Following the code path:

  • runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.cs

    Line 35 in 2e764d6

    public static CallInstruction Create(MethodInfo info, ParameterInfo[] parameters)

  • runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.cs

    Line 86 in 2e764d6

    res = FastCreate(info, parameters);

  • runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.Generated.cs

    Lines 44 to 154 in 2e764d6

    	switch (t.GetTypeCode())
    	{
    	case TypeCode.Object:
    	{
    	if (t != typeof(object) && (IndexIsNotReturnType(0, target, pi) || t.IsValueType))
    	{
    	// if we're on the return type relaxed delegates makes it ok to use object
    	goto default;
    	}
    	return FastCreate<Object>(target, pi);
    	}
    	case TypeCode.Int16: return FastCreate<Int16>(target, pi);
    	case TypeCode.Int32: return FastCreate<Int32>(target, pi);
    	case TypeCode.Int64: return FastCreate<Int64>(target, pi);
    	case TypeCode.Boolean: return FastCreate<Boolean>(target, pi);
    	case TypeCode.Char: return FastCreate<Char>(target, pi);
    	case TypeCode.Byte: return FastCreate<Byte>(target, pi);
    	case TypeCode.Decimal: return FastCreate<Decimal>(target, pi);
    	case TypeCode.DateTime: return FastCreate<DateTime>(target, pi);
    	case TypeCode.Double: return FastCreate<Double>(target, pi);
    	case TypeCode.Single: return FastCreate<Single>(target, pi);
    	case TypeCode.UInt16: return FastCreate<UInt16>(target, pi);
    	case TypeCode.UInt32: return FastCreate<UInt32>(target, pi);
    	case TypeCode.UInt64: return FastCreate<UInt64>(target, pi);
    	case TypeCode.String: return FastCreate<String>(target, pi);
    	case TypeCode.SByte: return FastCreate<SByte>(target, pi);
    	default: return SlowCreate(target, pi);
    	}
    	}
    	private static CallInstruction FastCreate<T0>(MethodInfo target, ParameterInfo[] pi)
    	{
    	Type t = TryGetParameterOrReturnType(target, pi, 1);
    	if (t == null)
    	{
    	if (target.ReturnType == typeof(void))
    	{
    	return new ActionCallInstruction<T0>(target);
    	}
    	return new FuncCallInstruction<T0>(target);
    	}
    	if (t.IsEnum) return SlowCreate(target, pi);
    	switch (t.GetTypeCode())
    	{
    	case TypeCode.Object:
    	{
    	if (t != typeof(object) && (IndexIsNotReturnType(1, target, pi) || t.IsValueType))
    	{
    	// if we're on the return type relaxed delegates makes it ok to use object
    	goto default;
    	}
    	return FastCreate<T0, Object>(target, pi);
    	}
    	case TypeCode.Int16: return FastCreate<T0, Int16>(target, pi);
    	case TypeCode.Int32: return FastCreate<T0, Int32>(target, pi);
    	case TypeCode.Int64: return FastCreate<T0, Int64>(target, pi);
    	case TypeCode.Boolean: return FastCreate<T0, Boolean>(target, pi);
    	case TypeCode.Char: return FastCreate<T0, Char>(target, pi);
    	case TypeCode.Byte: return FastCreate<T0, Byte>(target, pi);
    	case TypeCode.Decimal: return FastCreate<T0, Decimal>(target, pi);
    	case TypeCode.DateTime: return FastCreate<T0, DateTime>(target, pi);
    	case TypeCode.Double: return FastCreate<T0, Double>(target, pi);
    	case TypeCode.Single: return FastCreate<T0, Single>(target, pi);
    	case TypeCode.UInt16: return FastCreate<T0, UInt16>(target, pi);
    	case TypeCode.UInt32: return FastCreate<T0, UInt32>(target, pi);
    	case TypeCode.UInt64: return FastCreate<T0, UInt64>(target, pi);
    	case TypeCode.String: return FastCreate<T0, String>(target, pi);
    	case TypeCode.SByte: return FastCreate<T0, SByte>(target, pi);
    	default: return SlowCreate(target, pi);
    	}
    	}
    	private static CallInstruction FastCreate<T0, T1>(MethodInfo target, ParameterInfo[] pi)
    	{
    	Type t = TryGetParameterOrReturnType(target, pi, 2);
    	if (t == null)
    	{
    	if (target.ReturnType == typeof(void))
    	{
    	return new ActionCallInstruction<T0, T1>(target);
    	}
    	return new FuncCallInstruction<T0, T1>(target);
    	}
    	if (t.IsEnum) return SlowCreate(target, pi);
    	switch (t.GetTypeCode())
    	{
    	case TypeCode.Object:
    	{
    	Debug.Assert(pi.Length == 2);
    	if (t.IsValueType) goto default;
    	return new FuncCallInstruction<T0, T1, Object>(target);
    	}
    	case TypeCode.Int16: return new FuncCallInstruction<T0, T1, Int16>(target);
    	case TypeCode.Int32: return new FuncCallInstruction<T0, T1, Int32>(target);
    	case TypeCode.Int64: return new FuncCallInstruction<T0, T1, Int64>(target);
    	case TypeCode.Boolean: return new FuncCallInstruction<T0, T1, Boolean>(target);
    	case TypeCode.Char: return new FuncCallInstruction<T0, T1, Char>(target);
    	case TypeCode.Byte: return new FuncCallInstruction<T0, T1, Byte>(target);
    	case TypeCode.Decimal: return new FuncCallInstruction<T0, T1, Decimal>(target);
    	case TypeCode.DateTime: return new FuncCallInstruction<T0, T1, DateTime>(target);
    	case TypeCode.Double: return new FuncCallInstruction<T0, T1, Double>(target);
    	case TypeCode.Single: return new FuncCallInstruction<T0, T1, Single>(target);
    	case TypeCode.UInt16: return new FuncCallInstruction<T0, T1, UInt16>(target);
    	case TypeCode.UInt32: return new FuncCallInstruction<T0, T1, UInt32>(target);
    	case TypeCode.UInt64: return new FuncCallInstruction<T0, T1, UInt64>(target);
    	case TypeCode.String: return new FuncCallInstruction<T0, T1, String>(target);
    	case TypeCode.SByte: return new FuncCallInstruction<T0, T1, SByte>(target);
    	default: return SlowCreate(target, pi);

    (notice the use of generics over value types)

includes generating code for a lot of generic delegates and Mono tries its best to support these, but at what cost?

It is true that choosing delegates to implement fast invocation of methods should have better performance, but in case with Mono and delegates over value types, the compiler will generate GSHAREDVT methods (generic sharing for value types) which are actually quite slow.
On the other hand, NativeAOT does not have generic sharing for value types and generates instead all possible variations (causing the problem reported above 2) with a template MAUI app)

Risk assessment

Pros

• Reducing the gap in behaviour between MonoAOT and NativeAOT
• Better support for Linq.Expressions with Mono
• Enabling NativeAOT tests for Linq.Expressions on iOS-like platforms
• Estimated code size improvements:
  • NativeAOT ~30% smaller MAUI template app
  • MonoAOT ~2.5% smaller MAUI template app (the difference is way smaller compared to NativeAOT as Mono generates GSHAREDVT for fast invocation)
• Better user experience:
  • due to reported Attempting to JIT compile method (wrapper delegate-invoke) users had to enable mono interpreter in their projects (UseInterpreter=true) to cover-up for missing methods during runtime, which also affects the application size

Cons

• Regression in performance (to be confirmed)
  • This has to be measured and evaluated especially because MonoAOT uses GSHAREDVT in these cases

Proposal

Here is the list of tasks which should resolve all the reported issues around Linq.Expressions on iOS-like platforms

• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759
• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• [mono] Add conditional substitution for IsDynamicCodeSupported when targeting ios-like platforms #86971
• Set the IsDynamicCodeSupported feature to false when using FullAOT macios#18340
• [mono] Investigate enabling CanEmitObjectArrayDelegate to respect IsDynamicCodeSupported
  • As from my understanding this involves runtime support as well as noted here: Start building a universal System.Linq.Expressions library #61952 (comment) which might have been implemented already
• [NativeAOT] Enable Linq.Expressions tests on iOS-like platforms
• Remove individual feature switches introduced by NativeAOT: CanCompileToIL, CanEmitObjectArrayDelegate, CanCreateArbitraryDelegates
  • As they will be essentially replaced with IsDynamicCodeSupported
• [mono] Reenable testing of Linq.Expressions on iOS-like platforms
• [mono] Measure performance impact of using reflection over delegates in Linq.Expressions

---

Thanks to @MichalStrehovsky @vargaz @rolfbjarne for helping to identify these issues.

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	area-Codegen-AOT-mono, os-ios, area-NativeAOT-coreclr
Milestone:	8.0.0

[ivanpovazan]

/cc: @kotlarmilos @lambdageek @marek-safar @filipnavara

[ivanpovazan]

/cc: @SamMonoRT @eerhardt

[lambdageek]

Thanks Ivan. Can you or Michal explain the constant propagation issue? Is this some kind of IL trimmer bug - we substitute constants for feature switches all the time. Why is it a problem here?

My understanding is that the existing delegate-based approach will work with Mono AOT now.
What is the cost for NativeAOT to implement universal shared generics?

[filipnavara]

What is the cost for NativeAOT to implement universal shared generics?

I was asking about this multiple times already, and the answer was always that's it's intentionally not planned. .NET Native used to implement it (with different codegen backend), but any remains of the code were removed over time.

I don't think that Linq.Expressions would have any effect on the decision as the library itself is in archived state.

[ivanpovazan]

Thanks Ivan. Can you or Michal explain the constant propagation issue? Is this some kind of IL trimmer bug - we substitute constants for feature switches all the time. Why is it a problem here?

The problem is that two of the three mentioned control variables are configured as constants:

1. runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.cs

   Line 19 in 85a8413

   private static bool CanCreateArbitraryDelegates => true;

2. runtime/src/libraries/System.Linq.Expressions/src/System/Dynamic/Utils/DelegateHelpers.cs

   Line 15 in 85a8413

   internal static bool CanEmitObjectArrayDelegate => true;

3. The exception is:

   runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/LambdaExpression.cs

   Line 29 in 85a8413

   public static bool CanCompileToIL => RuntimeFeature.IsDynamicCodeSupported;

From my understanding, when the constant propagation is enabled during Linq.Expressions library build for iOS-like platforms, the first two will get removed and all the code paths they control, as they are constants. Once that happens, the feature switches ILC compiler depends on:

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

Lines 271 to 273 in 2aa0c9b

	<IlcArg Include="--feature:System.Linq.Expressions.CanCompileToIL=false" />
	<IlcArg Include="--feature:System.Linq.Expressions.CanEmitObjectArrayDelegate=false" />
	<IlcArg Include="--feature:System.Linq.Expressions.CanCreateArbitraryDelegates=false" />

become obscure, as these variables will not be present in the Linq.Expressions assembly for iOS-like platforms (this can be seen in the warning messages I pasted in the description).

Replacing them with a non-constant RuntimeFeature.IsDynamicCodeSupported would do the trick, as it would prevent them from being removed during the library build. What gets trimmed and AOTed further (during the app build) would then be properly controlled with DynamicCodeSupport feature switch (System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported documented here).

[lambdageek]

1. runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/CallInstruction.cs

   Line 19 in 85a8413

   private static bool CanCreateArbitraryDelegates => true;

2. runtime/src/libraries/System.Linq.Expressions/src/System/Dynamic/Utils/DelegateHelpers.cs

   Line 15 in 85a8413

   internal static bool CanEmitObjectArrayDelegate => true;

3. The exception is:

   runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/LambdaExpression.cs

   Line 29 in 85a8413

   public static bool CanCompileToIL => RuntimeFeature.IsDynamicCodeSupported;

Ah, I see. It's not a trimmer bug.
Would it be better if these three values should be their own top-level feature switches instead of constants in the source. and the SDKs should set them as appropriate if the trimmer isn't running.