* Events for IL methods without IL headers
Dynamically generated methods like UnsafeAccessor
functions are marked as IL, but don't contain an IL
header. The lack of header is an indication the IL must
be generated at runtime.
Co-authored-by: Tlakaelel Axayakatl Ceja <tlakaelel.ceja@microsoft.com>
- Refactor Module into ModuleBase and Module
- The goal is to have allow a subset version of Module which can only hold refs, this is to be used by the manifest module in an R2R image to allow for version resilient cross module references.
- Update handling of ModuleBase so that its used everywhere that tokens are parsed from R2R
- Remove ENCODE_MODULE_ID_FOR_STATICS and ENCODE_ACTIVE_DEPENDENCY
- These were only used for NGEN, and conflict with easy impelmentation for the ModuleBase concept
- Remove locking in ENCODE_STRING_HANDLE processing, and tweak comments. Comments applied to the removed ngen based code, and the lock was only necessary for the old ngen thing.
- Adjust ComputeLoaderModuleWorker for locating loader module
- Follow comment more accurately, to avoid putting every generic into its definition module. This will make R2R function lookup able to find compiled instantiations in some cases. This may be what we want long term, it may not.
- Remove MemberRefToDesc map and replace with LookupMap like the other token types. We no longer make use of the hot table, so this is more efficient
- Also reduces complexity of implementation of ModuleBase
- Build fixup to describe a single method as a standalone blob of data
- There are parallel implementations in Crossgen2 and in the runtime
- They produce binary identical output
- Basic R2RDump support for new fixup
- Adjust module indices used within the R2R format to support a module index which refers to the R2R manifest metadata. This requires bumping the R2R version to 6.2
- Add a module index between the set of assembly refs in the index 0 module and the set of assembly refs in the R2R manifest metadata
- Adjust compilation dependency rules to include a few critical AsyncStateMachineBox methods
- Remove PEImage handling of native metadata which was duplicative
- Do not enable any more devirtualization than was already in use, even in the cross module compilation scenario. In particular, do not enable devirtualization of methods where the decl method isn't within the version bubble, even if the decl method could be represented with a cross module reference token. (This could be fixed, but is out of scope for this initial investigation)
Make the compilation deterministic in this new model, even though we are generating new tokens on demand
- Implement this by detecting when we need new tokens during a compile, and recompiling with new tokens when necessary
- This may result in compiling the same code as much as twice
Compile the right set of methods with cross module inlining enabled
- Add support for compiling the called virtual methods on generic types
- This catches the List<T> and Dictionary<TKey,TValue> scenarios
- Support input of PGO data to control the set of methods
- Enable new `READYTORUN_FLAG_UNRELATED_R2R_CODE` flag on R2R images which is used to indicate which modules may have generic code not directly related to the metadata of the image
- Lookup R2R methods in an `alternate` location as well as the metadata defining module. This allows for many generics to be embedded without needing to use the new `READYTORUN_FLAG_UNRELATED_R2R_CODE` flag, which has global effects on performance.
- Add command line switches to enable/disable the new behavior
- Enhance the version resilience test to cover this new behavior
* Add support for cross module inlining and cross module generic compilation to Crossgen2
- Refactor Module into ModuleBase and Module
- The goal is to have allow a subset version of Module which can only hold refs, this is to be used by the manifest module in an R2R image to allow for version resilient cross module references.
- Update handling of ModuleBase so that its used everywhere that tokens are parsed from R2R
- Remove ENCODE_MODULE_ID_FOR_STATICS and ENCODE_ACTIVE_DEPENDENCY
- These were only used for NGEN, and conflict with easy impelmentation for the ModuleBase concept
- Remove locking in ENCODE_STRING_HANDLE processing, and tweak comments. Comments applied to the removed ngen based code, and the lock was only necessary for the old ngen thing.
- Adjust ComputeLoaderModuleWorker for locating loader module
- Follow comment more accurately, to avoid putting every generic into its definition module. This will make R2R function lookup able to find compiled instantiations in some cases. This may be what we want long term, it may not.
- Remove MemberRefToDesc map and replace with LookupMap like the other token types. We no longer make use of the hot table, so this is more efficient
- Also reduces complexity of implementation of ModuleBase
- Build fixup to describe a single method as a standalone blob of data
- There are parallel implementations in Crossgen2 and in the runtime
- They produce binary identical output
- Basic R2RDump support for new fixup
- Adjust module indices used within the R2R format to support a module index which refers to the R2R manifest metadata. This requires bumping the R2R version to 6.2
- Add a module index between the set of assembly refs in the index 0 module and the set of assembly refs in the R2R manifest metadata
- Adjust compilation dependency rules to include a few critical AsyncStateMachineBox methods
- Remove PEImage handling of native metadata which was duplicative
- Do not enable any more devirtualization than was already in use, even in the cross module compilation scenario. In particular, do not enable devirtualization of methods where the decl method isn't within the version bubble, even if the decl method could be represented with a cross-module reference token. (This could be fixed, but is out of scope for this initial investigation)
Make the compilation deterministic in this new model, even though we are generating new tokens on demand
- Implement this by detecting when we need new tokens during a compile, and recompiling with new tokens when necessary
- This may result in compiling the same code as much as twice
Compile the right set of methods with cross module inlining enabled
- Add support for compiling the called virtual methods on generic types
- This catches the List<T> and Dictionary<TKey,TValue> scenarios
- Add command line switches to enable/disable the new behavior
- By default the new behavior is not enabled
I noticed that some methods under dynamic PGO did not have PGO data.
Tracked this down to the Tier0 jit being unable to allocate a PGO schema.
This in turn was caused by the IL hash computation failing.
So, this PR fixes issues in the IL hash:
* pass in the right pointer to the IL
* advance the pointer as we scan the IL
* don't bail out early for the InlineNone case
Phase 1 of replacing existing infrastructure around handling of pgo data with more flexible schema based approach.
The schema based approach allows the JIT to define the form of data needed for instrumentation.
- The schema associates 4 32bit integers with each data collection point (ILOffset, InstrumentationKind, Count, and Other)
- Rich meaning is attached to InstrumentationKind, and Count
- InstrumentationKind defines the size and layout of individual instrumentation data items
- Count allows a single schema item to be repeated
- ILOffset and Other are not processed in any specific way by the infrastructure
Changes part of this phase
- PgoManager holds arbitrary amount of pgo data instead of a slab
- Aware of collectible assemblies
- Match with pgo data utilizes hash of IL body in addition to IL size information for greater accuracy in match
- JIT no longer uses block count apis, and instead uses schema based apis
- JIT now explicitly defines the shape of data collected for both basic block and type probes
- The rest of the system handles that without deep knowledge of what those formats are
- Text file format for pgo data updated
- Existing IBC infrastructure adjusted to speak in terms of schema concept
- Uncompressed and binary encoded implementation of Pgo schema handling
- Update SuperPMI to handle new apis
Future Changes for static Pgo
- Move Pgo type handle histogram processing into JIT
- Extract Pgo data from process using Event infrastructure
- Triggers for controlling Pgo data extraction
- Instrumented Pgo processing as part of dotnet-pgo tool
- Pgo data flow in crossgen2
* Move src/coreclr/src/Directory.Build.targets to src/coreclr
Merge src/coreclr/src/CMakeLists.txt into src/coreclr/CMakeLists.txt
* Mechanical move of src/coreclr/src to src/coreclr
* Scripts adjustments to reflect the changed paths
2020-12-08 03:19:44 +01:00
Renamed from src/coreclr/src/vm/versionresilienthashcode.cpp (Browse further)
