Simplify OptimizeGeneratedCodeHandler to speed up trimming

[marek-safar]

Existing OptimizeGeneratedCodeHandler logic duplicates a lot of processing and logic which is done as part of core IL linker steps. The code can be significantly simplified if migrated to use .NET6 features.

A proposal about how this can be done for each of the optimizations

ProcessCalls

EnsureUIThread

Convert field into property returning constant or add feature switch to set the value.

get_Size

Remove completely as it's done by linker by default.

get_IsDirectBinding

Set the constant via https://github.com/mono/linker/blob/main/src/linker/ref/Linker/Annotations.cs#L27-L28 for any override which should return true/false

get_DynamicRegistrationSupported

Remove completely, linker propagates the value already

SetupBlock and SetupBlockUnsafe

This would be much better done with source generator and can probably stay for now as it has nothing to do with linker.

ProcessLoadStaticField

IsARM64CallingConvention

I'm not sure why it's needed as field if we build arm64 specific runtime pack.

Arch

Should be a feature switch with which substitutes field

[spouliot]

EnsureUIThread
Convert field into property returning constant

Binary breaking change.

or add feature switch to set the value.

yes, that's was my plan.

[spouliot]

get_IsDirectBinding
Set the constant via https://github.com/mono/linker/blob/main/src/linker/ref/Linker/Annotations.cs#L27-L28 for any override which should return true/false

Can you explain how that works ?

IsDirectBinding is not a global constant. The value can be different for each NSObject subclass. In some cases (like if we know there's no subclasses for the type) this can be optimized. Otherwise the check must remain.

[spouliot]

get_DynamicRegistrationSupported
Remove completely, linker propagates the value already

This value is true for the original, compile code. However if/when we can remove the dynamic registrar (and drop a lot of code by doing so) then IIRC its updated to return false.

[spouliot]

IsARM64CallingConvention
I'm not sure why it's needed as field if we build arm64 specific runtime pack.

The (Xamarin.iOS) managed code has to call different p/invoke signatures based on the ABI.

[marek-safar]

The value can be different for each NSObject subclass. In some cases (like if we know there's no subclasses for the type) this can be optimized.

For those which you know it can be constant, you register the method with Annotations.SetAction (method, MethodAction. ConvertToStub) and set the value via Annotations.SetStubValue (method, 1)

However if/when we can remove the dynamic registrar

It was not clear to me if this should be configurable in net6 if so you keep it as it and add feature switch on top of it

managed code has to call different p/invoke signatures based on the ABI.

Right but it's already constant

xamarin-macios/src/ObjCRuntime/Runtime.cs

Line 1833 in 2b7dc07

return IntPtr.Size == 8 && Arch == Arch.DEVICE;

and if we add feature switch for Arch linker will automatically evaluate the method as constant returning.

[spouliot]

For those which you know it can be constant, you register the method with Annotations.SetAction (method, MethodAction. ConvertToStub) and set the value via Annotations.SetStubValue (method, 1)

I might be missing something obvious here but which method are you talking about in your code snippet ?

Example: Let's say that NSData.Foo and NSString.Bar have calls to the IsDirectBinding property.

By analyzing the app we know that

• NSMutableData is used and that it subclass NSData so we cannot optimize/remove the call to IsDirectBinding;
• NSString has no subclass (used by the app) so it does not need to call IsDirectBinding

So what's the method to be used ?

• it can't be NSData.Foo as it can not be optimized (would break the subclasses);
• NSString.Bar as it can be optimized ? but how does it know it's IsDirectBinding that can be optimized (and other other properties inside the method) ?
• NSObject.IsDirectBinding property ? it cannot be since optimizing this into NSObject would also apply to NSData ?

[spouliot]

or add feature switch to set the value.

yes, that's was my plan.

The easy/initial (not exhaustive) candidates for substitutions I identified are

API	Stubbed on
ObjCRuntime.Runtime::RegisterEntryAssembly [1]	Device
UIKit.UIButton::VerifyIsUIButton [2]	Release
UIKit.UIApplication::EnsureUIThread	Release [3]
UIKit.UIApplication::EnsureEventAndDelegateAreNotMismatched	Release [4]
UIKit.UIApplication::EnsureDelegateAssignIsNotOverwritingInternalDelegate	Release [4]

[1] #10457
[2] #9613
[3] can be overridden (legacy) with optional arguments
[4] were not removed by legacy linker

[marek-safar]

You could consider guarding some of them under the existing System.Diagnostics.Debugger.IsSupported feature switch which is unset for Release build.

[marek-safar]

I might be missing something obvious here but which method are you talking about in your code snippet ?

This will probably need a different approach than I thought. Based on your description it sounds that IsDirectBinding is another version of typeof (Foo) != GetType () comparison, right? If that's the case I believe the IL Linker will be able to understand that condition soon.