Make ILProvider configurable #6366
Conversation
Refactoring to allow us having custom IL providers. * The immediate goal is to allow specifying an IL provider for ready to run compilations that doesn't do the CoreRT-specific IL intrinsic expansion. * The medium term goal is to allow IL scanner to provide IL based on the scanning results. This allows optimization that Project N dependency reducer does, such as replacing IL bodies of instance methods on types that were never seen as allocated with `throw`. * The long term goal is to allow other IL level optimizations (based on the IL scanner or other inputs). This pretty much implements dotnet#6345 (comment), with some additions: I also got rid of `McgInteropSupport` (this is vestige of an old plan to do P/Invokes based on the MCG tool - we abandoned that plan), and I did a simplification in PrecomputedMetadataManager (we only want to read the ECMA IL - no need to use the full blown IL provider).
|
@jkotas could you have a look? src/Common/src/TypeSystem/IL/CoreRTILProvider.cs is a |
When I was testing dotnet#6366 in a mode we don't normally test (debug compiler with IL scanner enabled), I hit an assert around inconsistent reflection metadata for a Module type. Turns out we weren't tracking reflection on unconstructable types. Fixed that and added a test.
When I was testing #6366 in a mode we don't normally test (debug compiler with IL scanner enabled), I hit an assert around inconsistent reflection metadata for a Module type. Turns out we weren't tracking reflection on unconstructable types. Fixed that and added a test.
|
|
||
| public override MethodIL GetMethodIL(MethodDesc method) | ||
| { | ||
| MethodIL result = _primaryILProvider.GetMethodIL(method); |
There was a problem hiding this comment.
method.IsPInvoke ? _pinvokeProvider.GetMethodIL(method) : _primaryILProvider.GetMethodIL(method) ?
There was a problem hiding this comment.
Looks more readable - my micro-optimization is not worth it, fixed.
There was a problem hiding this comment.
I had to roll that back. This caused trouble with calli marshalling method thunks - they have IsPInvoke == true, but PInvokeILProvider can't provide method body for them because they're ILStubMethod and they provide their own IL.
| @@ -92,14 +94,18 @@ public CompilationBuilder UseDebugInfoProvider(DebugInformationProvider provider | |||
|
|
|||
| public abstract CompilationBuilder UseBackendOptions(IEnumerable<string> options); | |||
|
|
|||
| public abstract CompilationBuilder UseILProvider(ILProvider ilProvider); | |||
There was a problem hiding this comment.
I do not see UseILProvider called anywhere.
There was a problem hiding this comment.
This is a future extension point. I just wanted to see how it looked like (it got a bit tricky because I didn't want ILScanner to also have to choose the suitable ILProvider, but the base CompilationBuilder doesn't know it either). I can delete it for now, but I do have plans to use it.
| @@ -52,11 +52,7 @@ public ObjectNode GetFieldRvaData(FieldDesc field) | |||
|
|
|||
| internal MethodIL GetMethodIL(MethodDesc method) | |||
| { | |||
| // Flush the cache when it grows too big | |||
There was a problem hiding this comment.
This will not go through the cache anymore ... ok for JIT prototype, but it will likely need to be fixed eventually.
There was a problem hiding this comment.
Yeah, I didn't want to copy paste the cache. I don't like the current sharing plan between JitCompilation and Compilation (because the sharing plan is copy-paste). I think we should be able to at least do dot-file sharing, but I haven't thought about it too much yet. This file will have to be reconciled with Compilation.
Refactoring to allow us having custom IL providers.
throwmethod body.This pretty much implements #6345 (comment), with some additions: I also got rid of
McgInteropSupport(this is vestige of an old plan to do P/Invokes based on the MCG tool - we abandoned that plan), and I did a simplification inPrecomputedMetadataManager(we only want to read the ECMA IL - no need to use the full blown IL provider).