| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Rename method ICorJitInfo::allocBBProfileBuffer to ICorJitInfo::allocMethodBlockCounts
Rename method ICorJitInfo::getBBProfileData to ICorJitInfo:"getMethodBlockCounts
Rename args and use DWORD instead of ULONG for ICorJitInfo:allocMethodBlockCounts and ICorJitInfo:getMethodBlockCounts
Rename Compiler::fgProfileBuffer to Compiler::fgBlockCounts
Use an #ifdef FEATURE_CORECLR to fix the missing CORINFO_FLG_DISABLE_TIER0_FOR_LOOPS flag on the desktop.
Make fgBlockCountsCount and fgNumProfileRuns DWORDs instead of ULONGs
Rename local var bbCurrentBlockProfileBuffer to currentBlockCounts
Rename local var bbProfileBufferStart to profileBlockCountsStart
Use DWORD when iterating over BlockCounts instead of ULONG
Rename ZapImage::hashBBProfileData to ZapImage::hashMethodBlockCounts
SuperPMI - Fixed all references to allocBBProfileBuffer => allocMethodBlockCounts
SuperPMI - fixed all reference to getBBProfileBuffer => getMethodBlockCounts
|
|
This change improves detection of allocators with side effects.
Allocators can cause side effects if the allocated object may have a finalizer.
This change adds a pHasSideEffects parameter to getNewHelper JitEE interface
method. It's used by the jit to check for allocator side effects instead of
guessing from helper ids.
Fixes #21530.
|
|
|
|
This has two parts:
## Part 1
CoreRT represents native type handles differently from CoreCLR - on CoreCLR, `RuntimeTypeHandle` is a wrapper over `RuntimeType` and RyuJIT is aware of that. On CoreRT, `RuntimeTypeHandle` wraps the native type handle, not a `RuntimeType`.
The knowledge is hardcoded in importer when importing the sequence "ldtoken foo / call Type.GetTypeFromHandle" - importer just removes the call and bashes the result of ldtoken to be a reference type. CoreRT had to avoid reporting `Type.GetTypeFromHandle` as an intrinsic because of that.
I'm adding another helper that lets RyuJIT avoid hardcoding that knowledge. Instead of just bashing the return type, we swap the helper call.
## Part 2
Native type handle equality checks need to go through a helper, unless the EE side says it's okay to compare native type handles directly.
|
|
Add two methods to JitEE interface: getHeapClassSize and canAllocateOnStack.
Change JITEEVersionIdentifier.
|
|
|
|
|
|
|
|
Mark `EqualityComparer<T>.Default`'s getter as `[Intrinsic]` so
the jit knows there is something special about it. Extend the jit's
named intrinsic recognizer to recognize this method.
Add a new jit interface method to determine the exact type returned
by `EqualityComparer<T>.Default`, given `T`. Compute the return type by
mirroring the logic used in the actual implementation. Bail out when
`T` is not final as those cases won't simplify down much and lead to
code bloat.
Invoke this interface method when trying to devirtualize calls where
the 'this' object in the call comes from `EqualityComparer<T>.Default`.
The devirtualized methods can then be inlined. Since the specific comparer
`Equal` and `GetHashCode` methods look more complicated in IL than they
really are, mark them with AggressiveInlining attributes.
If devirtualization and inlining happen, it is quite likely that the value
of the comparer object itself is not used in the body of the comparer. This
value comes from a static field cache on the comparer helper.
When the comparer value is ignored, the jit removes the field access since it
is non-faulting. It also removes the the class init helper that is there to
ensure that the (no-longer accessed) field is properly initialized. This helper
has relatively high overhead even in the fast case where the class has been
initialized aready.
Add a perf test.
Closes #6688.
|
|
Support for new-style intrinsics where corelib methods can have both IL
implementations and optional jit-supplied implementations.
Mark such methods with the [Intrinsic] attribute, then recognize the
intrinsic methods by name in the jit.
Jit currently has a placeholder for the Enum.HasFlag method.
|
|
|
|
|
|
Create a new JitEE method expandRawHandleIntrinsic. Delete old isDelegateCreationAllowed and getAddrModuleDomainID.
Support CORINFO_INTRINSIC_GetRawHandle.
Change JITEEVersionIdentifier.
fix MEASURE_CLRAPI_CALLS: add resolveVirtualMethod and expandRawHandleIntrinsic there.
|
|
[tfs-changeset: 1652444]
|
|
* Remove COR_JIT_EE_VERSION define
Currently, we maintain two versions of the JIT-EE interface in the
source tree: the current version, and .NET 4.6 version. This is
managed by the `COR_JIT_EE_VERSION` define. Any new changes to the JIT-EE
interface must be put under `#if COR_JIT_EE_VERSION > 460`. As of now,
there are quite a few of these `#if` statements in the tree.
We started doing this so we could build and ship a CTP (Community
Technology Preview) version of the JIT from the current source tree that
runs against earlier versions of the runtime that are widely available
to customers, so those customers can try out the new JIT and give us
early feedback. This was done during the RyuJIT/x64 bring-up before
shipping .NET 4.6, to get as much feedback as possible before replacing
JIT64. After 4.6 shipped, we re-based the old version of the JIT-EE
interface to the 4.6 version, and started adding the above `#if`
conditions, with the thought that if we ever shipped another CTP, it
would be expected to run on top of 4.6. We have not shipped such a
thing, and we currently have no plans to build another CTP in the same
way we did before. (Early adopters can try out the "live" JIT in the
.NET Core open source project, although that JIT can't be used on the
desktop.)
So, to simplify the code, and reduce the cost of adding to or changing
the JIT-EE interface, we are removing the `COR_JIT_EE_VERSION` define.
|
|
* Add option to measure time spent inside calls to the CLR (off by default).
|
