| Age | Commit message (Collapse) | Author |
|---|
|
Simulates what JitInterface operates on.
|
|
Since we currently allow unnormalized things in the dependency graph (see #5264), we need to ensure scanner produces a dependency graph that can be queried for unnormalized vtable slices.
This fixes a regression in a ASP.NET scenario. Also fixes #5508.
|
|
Picks up:
* dotnet/coreclr#13561
* dotnet/coreclr#13577
Fixes #3608.
|
|
Refactor GVM algorithm for better performance
Fix GVM resolution bug on derived types
Fix bug with variance (https://github.com/dotnet/corert/issues/3454)
|
|
|
|
Canonical EETypes weren't reporting their virtual method dependencies,
hoping that by the time they want to emit the VTable, someone else
already reported them. Fixing that by moving virtual method reporting
from `ConstructedEETypeNode` down to `EETypeNode`. At this point it's
really obvious that the current object hierarchy (where `EETypeNode`
represents an unconstructed EEType that shouldn't care about virtuals,
but handles pretty much all of it anyway) doesn't work.
Fixes #3659.
|
|
* Make virtual invoke map report dependency on virtual method slot
Placing a virtual method in the map means that we'll need a slot for it.
I wasn't sure I liked this as a fix in the past, because it makes the
mapping table potentially bring unused methods into the compilation
(e.g. if the method has multiple overrides), but I convinced myself that
doing anything else would result in terrible user experience and
whatever external tool we'll use to determine reflection roots in the
future will need to apply the same rule.
* Fix release test failure
|
|
Turns out I got most of this right in #3318. At that time I saw RyuJIT
crashing but didn't have a checked version of it handy. Turns out it was
just an eager assert that is easy to subdue.
|
|
This used to work but it's now failing in the rolling build. It's easy
enough to restore enough of the functionality to get the tests passing
again.
The rest of the work (creating the delegate from shared code) is tracked
in #2796 (uncomment the commented out test line to hit a failure in the
JIT).
|
|
Update the compiler to be able to leverage the newly added RyuJIT capabilities around delegate constructions.
In the past, RyuJIT would only ask for the construction helper for the simplest cases (target method is not virtual, and no generic runtime lookup is needed). It would call the actual constructor method for everything else.
With updated RyuJIT, we can now use the helper in all cases (if the construction pattern is verifiable).
The change is bigger than I would like because:
* We needed to update `DelegateCreationInfo` to capture the fact that the target of the delegate can now be runtime determined
* There was an unimplemented feature around fat function pointers looked up from dictionaries (we couldn't express that the fat function pointer should point to the unboxing stub).
* `ShadowConcreteMethod` didn't work great with unboxing stubs. I just made a new node that is a "shadow unboxing stub".
* We needed to update both generic and nongeneric ready to run helpers to deal with the new delegate creation patterns.
* JitInterface change.
* Tests
|
|
|
|
when ILCompiler.DependencyAnalysis.RyuJitNodeFactory is MarkingComplete (#3227)
|
|
The dynamic invoke tests were failing because the JIT was inlining all the target methods leaving nothing to actually invoke through reflection. Mark all the methods we invoke (including the empty constructors) with `[MethodImpl(MethodImplOptions.NoInlining)]`.
[tfs-changeset: 1653296]
|
|
* Add CoreRT implementation for the dynamic invoke template table which maps invoke stub name / sig to the canonical method entrypoint
* CoreRT based compilers use 32bit relative addresses to the stub containing EEType and method entry points (.NET Native uses RVAs). Set the bit on the reloc to indicate a 32bit rel reloc.
* Fix a bug in generic method template map where generic methods on structs were getting IsUnboxingStub set incorrectly
[tfs-changeset: 1653288]
|
|
Support GC Statics in type loader
* Add support for CoreRT-style GC statics when creating new generic types from templates
* Pass new `BagElementKind.GCStaticEEType` through in the template layout so the type's statics can be heap-allocated
* Add managed accessors to the dynamic GC / non-GC data to EEType.cs
|
|
to virtual and generic virtual methods. (#3100)
Implementation supports both CoreRT and ProjectX models.
Fixed interface EEType generation to unconditionally produce a dictionary slot for generic interfaces (to support static interface methods, and enable correct Reflection virtual invoke slot computation on ProjectX).
|
|
* Enable template generation for generic types
* Dictionary slots generated for types / methods cause that type / method to get a type loader template
* Remove the template-specific list of slots and just use the owning type's dictionary layout
* Add not-supported entry for template slots that aren't implemented yet
[tfs-changeset: 1651962]
|
|
1) Adding the StaticsInfoHashtable to track statics regions for compiled types.
2) Writing statics field data to the ReflectionFieldMapNode
3) Improving the IndirectionNode to allow it to point to an inner offset in a target symbol
4) CoreRT runtime support for static fields access
5) Collapsing of field entries in the ReflectionFieldMapNode based on canonicalization
|
|
Pull request #2096 made sure that lazily built vtables of `Foo<X>` and
`Foo<Y>` contain the same entries if their canonical forms are the same,
but didn't make sure the order of the entries is the same. This can lead
to bugs at runtime where the wrong slot is used to dispatch a virtual
method call. To make sure the vtables look the same, we need to also
sort the vtable.
|
|
The delegate creation code path wasn't updated for shared generics:
* We need to use canonical entrypoints and fat function pointers where appropriate
* This required adding infrastructure to track unboxing stubs from shared code.
More work will be needed around here to add support for creating delegates *from* shared code.
|
|
|
|
This test outlived its usefulness.
|
|
|
|
This doesn't need a runtime lookup, but RyuJIT is asking for one.
|
|
Enabling GVM target resolution (hookup work)
|
|
|
|
I admit this required special casing in places I don't like, but the
`Address` methods on multidimensional arrays are... well, special.
The problem with the `Address` method is that it needs to do an exact
type check in it's body - the array element type that is expected at the
callsite needs to match the runtime type of the array passed in. We need
this because of array covariance (`string[`]` is allowed to be cast to
`object[,]` and we need to disallow making a `ref object` to an array
element if the runtime type of the array is not exactly `object[,]`).
This changes mirrors how Address methods get compiled on CoreCLR. The
story begins at the callsite:
1. We tell the codegen in `getCallInfo` that `Address` is a method that
requires an instantiation argument (just like e.g. static methods on
shared generic types), but disallow inlining it so that we are forced to
generate a standalone body. Method's owning type becomes the
instantiation argument.
2. We make sure the dependency tracking doesn't track the `Address`
method as a runtime determined method. It's difficult to represent it in
the RuntimeDetermined infrastructure (for the simple reason that
RuntimeDetermined types need to be DefTypes). We can get away with it
because the `Address` method doesn't actually do generic lookups anyway.
3. When we get to compile the method body, we pull the old switcheroo
and replace the method with one that has the instantiation argument in
the signature (so that we can refer to the argument from IL). We then
use the hidden argument to do the type check within the method body.
|
|
The fact we could reflection enable two instantiations of a method
relied on pure luck on which invoke stub we choose to invoke the method.
If we chose the one for `object`, we could use it to invoke the method
instantiated over `string`. We ran out of luck in postcheckin.
I'm fixning the test to only have one generic method instantiation to
make it pass again to keep coverage for the other interesting cases.
Making this actually work depends on the "Use type loader to build
invoke stub dictionaries" workitem. Requires type loader.
|
|
To support calling canonical interface methods on generic valuetypes,
the compiler needs to generate unboxing+instantiating thunks that bridge
the difference between two calling conventions.
As a refresher:
* Instance methods on shared generic valuetypes expect two arguments
(aside from the arguments declared in the signature): a ByRef to the
first byte of the value of the valuetype (`this`), and a generic context
argument (EEType)
* Interface calls expect `this` to be a reference type (with the generic
context to be inferred from `this` by the callee)
Instantiating and unboxing stubs bridge this by extracting a managed
pointer out of a boxed valuetype, along with the EEType of the boxed
valuetype (to provide the generic context) before dispatching to the
instance method.
We compile them by:
* Pretending the unboxing stub is an instance method on a reference type
with the same layout as a boxed valuetype
* Having the unboxing stub load the `m_pEEType` field (to get generic
context) and a byref to the actual value (to get a `this` expected by
valuetype methods)
* Generating a call to the instance method on the valuetype through a
wrapper that has an explicit generic context parameter in it's
signature.
|
|
This is a bunch of things:
* Make the reflection dynamic invoke thunk use the transformed calli
intrinsic to do the call (to handle fat function pointers)
* Generic dictionary nodes are prefixed with the hash code, but I put
the padding in the wrong location. That's what I get for writing code
off memory without crosschecking with Project N binder...
* Make MethodCodeNode depend on it's unboxig stub. This is in the hacky
section with a big comment explaining why we need it for now. (Method
being compiled determines it's reflectability.)
* Emit a pointer to the unboxing stub in the reflection mapping table if
needed.
* Remove a another usage of GetRvaFromIndex from the type loader
* Add a test
|
|
Don't track runtime determined dependencies if we're generating a call
to a constrained method.
The more complicated case is tracked in #2526.
|
|
This adds support for generating helpers and dictionary entries to
support thread static base lookups for generic types in shared generic
context.
I slightly tweaked how dictionary slots get emitted because the "every
slot is an `ISymbolNode`" paradigm wasn't very flexible.
|
|
* Static methods on generic types use the type's generic dictionary
Dependency analysis was incorrectly assuming these have their own
dictionary (they don't).
* Emit R2R generic helpers for ldvirtftn
|
|
In order to compile larger bodies of code (such as XUnit) without full
GVM support, emit a R2R helper at GVM callsites that fails fast at
runtime. I left the check for GVMs in-place in
`ConstructedEETypeNode.OutputVirtualSlots` to make sure we don't
actually put them in the VTable since they'll eventually be dispatched
via a lookup table.
|
|
When the generic ready to run lookup helper needs to know the generic
dictionary vtable slot, it passes the canonical type to the helper that
determines the slot. `GetNumberOfBaseSlots` needs to be able to deal
with this, and the fact that the slots might be lazily determined.
Converting to canon fixes this due to how we ensure canonically
equivalent types have the same vtable in #2096. The other option would
be to back out that change and completely revamp how we do lazy slots
for generic types.
I found this when I ran the reflection invoke test with shared generics
enabled.
|
|
|
|
This lets us get at least some test coverage for delegate invocation in
shared generics mode before #2102 gets fixed.
|
|
|
|
|
