| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* CreateAgnostic_CORINFO_SIG_INFO
Also you pSig_Index always when it is index in the buffer map,
as we do for sigInst_classInst_Index for example.
* spmi Restore_CORINFO_RESOLVED_TOKENout
delete another duplicate.
* SpmiDumpHelper
|
|
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.
|
|
* [x86/Linux] Use CDECL as STDAPICALLTYPE
* Use system default calling convention for internal functions
|
|
Apply jit style format on spmi sources.
|
|
Change JIT-EE interface for getReadyToRunDelegateCtorHelper.
Update GUID.
|
|
|
|
Extend resolveVirtualMethod to take in the owner type needed to resolve
shared generic interface calls, and implement VM support for interface
call devirtualization. Add a check that the class presented by the jit
implements the interface, to catch cases where the IL is missing type
casts.
Update jit GUID, SPMI and zap to reflect the changed signature.
|
|
Add new method to jit interface so the jit can determine what derived
method might be called for a given base method, derived class pair.
Implement support in the VM and in other places (zap, spmi).
|
|
The "JIT flags" currently passed between the EE and the JIT have traditionally
been bit flags in a 32-bit word. Recently, a second 32-bit word was added to
accommodate additional flags, but that set of flags is definitely "2nd class":
they are not universally passed, and require using a separate set of bit
definitions, and comparing those bits against the proper, 2nd word.
This change replaces all uses of bare DWORD or 'unsigned int' types
representing flags with CORJIT_FLAGS, which is now an opaque type. All
flag names were renamed from CORJIT_FLG_* to CORJIT_FLAG_* to ensure all
cases were changed to use the new names, which are also scoped within the
CORJIT_FLAGS type itself.
Another motivation to do this, besides cleaner code, is to allow enabling the
SSE/AVX flags for x86. For x86, we had fewer bits available in the "first
word", so would have to either put them in the "second word", which, as
stated, was very much 2nd class and not plumbed through many usages, or
we could move other bits to the "second word", with the same issues. Neither
was a good option.
RyuJIT compiles with both COR_JIT_EE_VERSION > 460 and <= 460. I introduced
a JitFlags adapter class in jitee.h to handle both JIT flag types. All JIT
code uses this JitFlags type, which operates identically to the new
CORJIT_FLAGS type.
In addition to introducing the new CORJIT_FLAGS type, the SSE/AVX flags are
enabled for x86.
The JIT-EE interface GUID is changed, as this is a breaking change.
|
|
OVERVIEW
========
This directory contains the SuperPMI tool used for testing the .NET
just-in-time (JIT) compiler.
SuperPMI has two uses:
1. Verification that a JIT code change doesn't cause any asserts.
2. Finding test code where two JIT compilers generate different code, or verifying
that the two compilers generate the same code.
Case #1 is useful for doing quick regression checking when making a source
code change to the JIT compiler. The process is: (a) make a JIT source code
change, (b) run that newly built JIT through a SuperPMI run to verify no
asserts have been introduced.
Case #2 is useful for generating assembly language diffs, to help analyze the
impact of a JIT code change.
SuperPMI works in two phases: collection and playback. In the collection phase,
the system is configured to collect SuperPMI data. Then, run any set of .NET managed
programs. When these managed programs invoke the JIT compiler, SuperPMI gathers and
captures all information passed between the JIT and its .NET host. In the
playback phase, SuperPMI loads the JIT directly, and causes it to compile all
the functions that it previously compiled, but using the collected data to
provide answers to various questions that the JIT needs to ask. The .NET
execution engine (EE) is not invoked at all.
TOOLS
==========
There are two native executable tools: superpmi and mcs. There is a .NET Core
C# program that is built as part of the coreclr repo tests build called
superpmicollect.exe.
All will show a help screen if passed -?.
COLLECTION
==========
Set the following environment variables:
SuperPMIShimLogPath=<full path to an empty temporary directory>
SuperPMIShimPath=<full path to clrjit.dll, the "standalone" JIT>
COMPlus_AltJit=*
COMPlus_AltJitName=superpmi-shim-collector.dll
(On Linux, use libclrjit.so and libsuperpmi-shim-collector.so. On Mac,
use libclrjit.dylib and libsuperpmi-shim-collector.dylib.)
Then, run some managed programs. When done running programs, un-set these variables.
Now, you will have a large number of .mc files. Merge these using the mcs
tool:
mcs -merge base.mch *.mc
One benefit of SuperPMI is the ability to remove duplicated compilations, so
on replay only unique functions are compiled. Use the following to create a
"unique" set of functions:
mcs -removeDup -thin base.mch unique.mch
Note that -thin is not required. However, it will delete all the compilation
result collected during the collection phase, which makes the resulting MCH
file smaller. Those compilation results are not required for playback.
Use the superpmicollect.exe tool to automate and simplify this process.
PLAYBACK
========
Once you have a merged, de-duplicated MCH collection, you can play it back
using:
superpmi unique.mch clrjit.dll
You can do this much faster by utilizing all the processors on your machine,
and replaying in parallel, using:
superpmi -p unique.mch clrjit.dll
REMAINING WORK
=============
The basic of assembly diffing are there, using the "coredistools"
package. The open source build needs to be altered to use this package
to wire up the correct build steps.
[tfs-changeset: 1623347]
|
