[mono] Optimize and clean-up System.Reflection.Emit.ILGenerator.

[teo-tsirpanis]

I noticed that the ILGenerator class in Mono uses an object stack to store integers, boxing them for no reason, and that some code that emits numbers in the code stream can be simplified with the help of members of the BinaryPrimitives class. This PR fixes both things.

[ghost]

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

Issue Details

---

I noticed that the ILGenerator class in Mono uses an object stack to store integers, boxing them for no reason, and that some code that emits numbers in the code stream can be simplified with the help of members of the BinaryPrimitives class. This PR fixes both things.

Author:	teo-tsirpanis
Assignees:	-
Labels:	area-System.Reflection.Emit, community-contribution
Milestone:	-

[stephentoub]

How much work would it be to instead unify on coreclr's ILGenerator, moving that to shared and only specializing for runtime where there's a real need for divergence?

[teo-tsirpanis]

That's a nice idea but not something at least I intend to do any time soon. Better open a new issue to not forget it.

[lambdageek]

How much work would it be to instead unify on coreclr's ILGenerator, moving that to shared and only specializing for runtime where there's a real need for divergence?

it's probably not too much work. The CoreCLR implementation uses SignatureHelper.GetLocalVarSigHelper (Module? module) which is ok. The place where things get tricky is in code like DynamicILInfo that uses SignatureHelper.GetLocalVarSigHelper() (no arguments). The no-args signature helper will require mono to implement ELEMENT_TYPE_INTERNAL in order to represent pointers to runtime types in ECMA IL signatures (which are just byte arrays) which is going to be a more involved project.

I have some notes in a Paper doc

[marek-safar]

Thank you!