| Age | Commit message (Collapse) | Author |
|---|
|
* Determinism test harness
Add a /determinism mode to runtest.cmd that will invoke ILC twice with different random determinism seeds. This causes graph expansion to be randomized based on seed (though deterministic for a given seed).
* Add Utf8String.CompareTo
Implementation taken from S.P.CoreLib. All the loop unrolling optimizations were excluded; we re-implement them if this function becomes a perf bottleneck.
* Define the mechanisms for determinism
To ensure deterministic output, all nodes that are emitted to the binary are sorted after compilation when retrieving the final marked nodes list. The overall approach is to sort nodes of the same type together (ie, all EETypeNodes come before NonGcStaticsNodes). Within nodes of the same type, a comparison function uses a CompilerComparer to compare the key identifying data of a node. For example, an EETypeNode is defined by a TypeDesc. The CompilerComparer provides a stable comparison function for comparing various type system primitives. Some nodes need to be emitted in an early and specific order for compiler correctness; this is provided by partitioning all sorted nodes into two phases: the first phase containined specifically ordered nodes, and a second phase for all other nodes whose ordering in the output binary doesn't matter.
Add SortableDependencyNode abstract class which provides the sortability layer on top of a DependencyNodeCore. Both ObjectNode and EmbeddedObjectNode derive from SortableDependencyNode to provide sortability across all nodes that are emitted to the output binary.
Introduce `ISortableSymbolNode` to provide sortability for nodes that are currently referred to in the compiler via the ISymbolNode interface. Such nodes are actually `ObjectNode` or `EmbeddedObjectNode` instances that we've lost type information for. Instances that implement `ISortableSymbolNode` redirect to the matching SortableDependencyNode methods.
Add `EmbeddedDataContainerNode` as a base class of `ArrayOfEmbeddedDataNode` to allow comparison of different instantiations.
Refactor the interface dispatch map index calculation so it's done when the dispatch map is emitted at the end of compilation. Previously it was done when the indirection cell in the dispatch map array got marked. This mechanism is incompatible with generating stable dispatch map indices. The arrays of embedded nodes now stabilize IDs as they emit their final data. This introduces an output ordering dependency - OptionalEETypeNodes must be emitted after the dispatch map since they encode dispatch map indices. Manually enforce this with C++ code generation, since it doesn't emit the real dispatch map structure and builds its own.
Modify InterfaceDispatchMapNode to use the type name in name mangling instead of an index into the dispatch map table.
Modify ObjectDumper to also amit a sha256 hash of each node's data. This dump is used to diff the map files and prove determinism.
* Fill out ordering functions for all nodes
Most of these are not very interesting. Here's the overall approach:
- Every different type of node needs a unique ClassCode. These were generated using Math.Random.
- The various metadata / native layout nodes plus arrays of EmbeddedObjectNodes get placed in the Ordered phase with specific ordering of each.
- All other nodes go in the Unordered phase
- To order nodes of the same type, the data that represents the key for the node in NodeFactory is compared. Ie, for an EEType, that would be its defining TypeDesc, whereas a FrozenStringNode is defined by the string it represents).
- The marked nodes list also contains raw DependencyNodeCore<T> nodes, which aren't emitted. Those are all shuffled after the emitted nodes and not sorted amongst themselves. That hasn't proven to be a problem with determinism and saves a bunch of hopefully unnecessary comparisons.
|
|
- Pick up latest .NET Core 2.0 CLI and buildtools
- Remove all project.json references and convert everything to msbuild projects
- Stick to vanilla .NET CLI project shape as much as possible. Minimize dependencies on buildtools special behaviors
|
|
|
|
The latest project templates do not have it, and it is only good for generating warnings like the following in the detailed build log:
Project file contains ToolsVersion="4.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="14.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
[tfs-changeset: 1662024]
|
|
This exposes a command line switch to enable IL scanner. When IL scanner is enabled, it determines the shape of all VTables to be used during compilation, allowing codegen to generate inline vtable lookups (instead of calling an assembly helper that does the lookup).
* Factoring of Compilation and ILScanner so that they both can provide lists of compiled methods and generated EETypes
* `IMethodBodyNode` to mark the node that represents a method body in a given compilation.
* Diff the results of scanning and compilation phases to find potential issues in the scanner.
* Native layout is asking for vtables of RuntimeDetermined things. Switching it over to ask for the canon versions.
Known analysis discrepancies:
* SIMD intrinsics not getting recognized as intrinsics in the scanner. There's just too many of them. Worked around by ignoring all scan/compilation diffs in the SIMD module.
* Type system entities injected by interop/reflection not surviving across scan/compile phases. For now, ignoring them under an active issue (#3873)
|
|
computed results (90% perf improvement on Release builds for the ASPNet benchmark app (22 mins to 2 mins total compile time) (#3652)
|
|
This adds an initial implementation of an IL scanner that will scan method bodies, starting from the provided compilation roots, and expand the dependency graph based on scanning the IL, to determine the set of methods (and types, and other interesting artifacts) that will be compiled.
This nicely plugs into the existing architecture where the scanner looks almost just like another codegen backend - we have a separate NodeFactory for it, a separate builder class, and a separate compilation class. The actual IL parsing reuses the importer written for CppCodegen and ILVerifier.
The results of the scanning phase will flow into the metadata generator and potentially other parts of the system.
|
|
FirstMarkLogStrategy.VisitLogNodes contains a HashSet,
combinedNodesReporting, that ensures we only report duplicate combined
dependencies once. We were checking the HashSet didn't already contain
an entry but failing to add the entry after visiting the node.
|
|
- Refactorings and tweaks of various ILCompiler infrastructure to allow use within the runtime
- Refactor delegate creation info off of CompilerTypeSystemContext onto TypeSystemContext
- Tweak jit interface to always refer to nodes via interfaces instead of concrete types
- adjust CorInfoImpl.constructStringLiteral to respect the RepresentsIndirectionCell flag
- Initial copy of JitCodeManager. Currently only supports Windows.
- System.Private.Jit
- Uses infrastructure from the ILCompiler such as the CorInfoImpl, jitinterface, and the dependency node infrastructure to define a way to express newly generated code and its dependencies.
- Where relocs from jitted code depend on resolving to other components, they are always indirected through an indirection cell, and the final value is computed by the dynamic type loader GenericDictionaryCell system (which is poorly named, and is actually a general purpose runtime component resolution system.)
- New concept of dynamic MethodEntrypoints in the type loader. This is used to bridge to the jit where necessary
- The various bits of build time goo to produce experimental versions of System.Private.Reflection.Core, System.Private.Reflection.Execution, and System.Private.TypeLoader which contain the ECMA based type loader, and support the jit.
- The new behavior is only enabled for these new experimental builds.
- As the existing ECMA 335 based typeloader/reflection logic hasn't been enabled for building, there are fixes to make it work again
[tfs-changeset: 1651156]
|
|
Remove most of the usages of static name mangler
|
|
This is so that "this node is implemented in the same assembly as the
dependency analysis framework" and "this node is implemented in a
different assembly" doesn't require conflicting accessibility rules on
`GetName` overrides (one is "protected internal" the other is just
"protected").
|
|
|
|
|
|
[tfs-changeset: 1650235]
|
|
ExternMethodSymbolNodes
- Remove current duplicate nodes
- Distinguish between methods compiled in current compilation and code referenced from other modules
- Add IDependencyNode concepts so that ShadowConcreteMethodNode can work off of an interface only. (Also, made ISymbolNode inherit from it, so that we can easily do more such work)
[tfs-changeset: 1650230]
|
|
We agreed in the past that `ToString` is allowed to return
debugger-friendly strings and doesn't need to be the symbolic name.
Disentangle pieces of `DgmlWriter` so that it can call the right method
instead of `ToString`.
This is a step towards getting rid of the static name mangler. In the
next step, `GetName` will be updated to accept a `DependencyContextType`
parameter (`NodeFactory` in the `ILCompiler` world) so that it can get
to the `NameMangler` associated with the factory and we can get rid of
the static that makes everything non-unit testable (two different name
manglers can't coexist in a single process right now), limiting what we
can test in xunit.
|
|
* Update BuildToolsVersion to latest
* Cleanup CLSCompliant warnings
* Delete workaround that is no longer needed
* Download .NET Core 1.1
* Fix Roslyn props
* MSBuild.exe was renamed to MSBuild.dll
* Fix CoreCLR tests
* Rename netcoreapp12 -> netcoreapp20
* Fix UnitTests runs
* Fix RemoveEmptyFinalizers CodeAnalysis warnings
* Port init-tools.sh cleanup from CoreCLR
|
|
|
|
[tfs-changeset: 1646943]
|
|
* Add a few new node types used when the UTC compiler hosts ILCompiler:
`ThreadStaticsIndexNode`, `ThreadStaticsOffsetNode`, `GCStaticDescNode`,
`UtcDictionaryLayoutNode`.
* Add a UTC-specific `UtcNodeFactory`
* Various type visibility changes
|
|
This thing is useless in the VS Solution Explorer and has an annoying
warning sign.
|
|
|
|
- s/readonly static/static readonly/
- s/static internal/internal static/
- s/static private/private static/
- s/static public/public static/
- s/static protected/protected static/
- s/unsafe static/static unsafe/
- s/unsafe extern/extern unsafe/
- s/internal protected/protected internal/
|
|
`GetName` is "get the name to be used in the diagnostic log". The rules
around it in the compier are:
* if the node is a `ISymbolNode` it should include the mangled name so
that it's easy to crossreference it with the object file (doesn't
necessarily have to be equal to the mangled name - see EETypeNode and
friends that append "constructed", etc.)
* if the node is not an `ISymbolNode`, get something that will be useful
to search for in the dependency log
I'm making the API protected and internal to avoid misuse and fixing the
places misusing this API (the spot in ObjectWriter was just wrong,
CppWriter was okay, but with problems waiting to happen).
I'm also unsealing ToString. We'll want to override it on a case-by-case
basis to make debugger experience more pleasant.
|
|
|
|
Today I learned: omitting the `private set;` part will make the C#
compiler emit a `initonly` backing field (and as such, allow assigning
the property in the constructor only).
|
|
|
|
Seal Equals and GetHashCode on DependencyNode
|
|
This was falling back to the runtime supplied implementation which has
pretty bad perf characteristics.
Also made the fields read only and implemented IEquatable for good
measure.
|
|
Dependency nodes always use referential equality. Trying to provide
other semantics would break the dependency analysis engine, so let's
forbid that.
|
|
Add ubuntu.14.04-x64 and osx.10.10-x64 to list of supported runtimes.
|
|
This version has the "make ILPROJ project buildable from VS" fix.
|
|
|
|
|
|
|
|
Seems like the only value we were getting out of it was this warning as
part of the build:
```
Found conflicts between different versions of the same dependent
assembly that could not be resolved.
```
I can live without that.
|
|
|
|
This reverts commit 374d1f1f2d901b4ef1096fbac2bb3da85e73949e.
This reverts commit 81fe8e5d944fdbe2560815f4aead1ab4a447fb5a.
This reverts commit 3d2d89e793d1588e1aa7d2273fc880ae208352f5.
This reverts commit a1f2ba2cae2dac1d134ae9afd60462cf57dde3c3.
|
|
This reverts commit 766f4ea7ff4d9dcd0422da1ebd115eb6b279e684, reversing
changes made to ce31cfa86e2d82af79212a1b09b7c1fe05baf3f6.
Revert "Merge pull request #767 from schellap/wmain"
This reverts commit 86e568eb6e82e2526ace252fcb49903e298e708d, reversing
changes made to 1d3ef5fd841effc0599511e3073a0cad53bed88b.
Revert formatting to old project.json and cppcompilerflag in runtest.cmd
|
|
|
|
Conflicts:
src/Common/src/Interop/Windows/mincore/Interop.MEMORY_BASIC_INFORMATION.cs
src/ILCompiler.Compiler/src/Compiler/PdbSymbolProvider.cs
src/Native/Bootstrap/platform.h
src/Native/Bootstrap/platform.windows.cpp
src/Native/gc/env/gcenv.windows.cpp
src/System.Private.CoreLib/src/Internal/Runtime/CompilerHelpers/ArrayMethodILHelpers.cs
tests/src/Simple/AsgAdd1/AsgAdd1.cs
|
|
|
|
The hook looks for assembly with .McgInterop suffix. If there is one, the PInvoke
marshalling code is forwarded to it. Otherwise, the existing ILEmitter-bases solution
is used.
|
|
|
|
|
|
Using the https://github.com/dotnet/codeformatter tool with the
following command line:
/rule-:FieldNames,ReadonlyFields ILCompiler.sln
|
|
- Rename the compiler .exe to ilc.exe
- Rename ILToNative.* to ILCompiler.* everywhere else
|
