| Age | Commit message (Collapse) | Author |
|---|
|
I'm looking at size regressions between .NET Native 1.7 and the current mainline branch. A thing that stood out is universally bigger EETypes. A contributor to this was getting rid of GenericInstanceDescs between 1.7 and 2.0 and replacing them by direct references to generic composition details from the EEType. Size-wise, this was mostly a wash, but we can actually do better - these new fields are not critical to be pointer-sized.
This change turns them into relative pointers. This saves 33 kB on a hello world app. I expect around 100 kB savings on the UWP People app based on my back-of-the-envelope calculation.
Project N baggage:
1. Update pntestcl build configuration to compile it with a C# compiler that is not 8 years old
2. Disable metadata validation transform on class libraries. This is hitting what appears to be a CCI metadata validator bug (Validator.cs:796) where it thinks a modified type should have the same interned key as the unmodified version of it. The act of resolving a modified type strips off the modifier. This ticks off the validator.
3. Fix a Reducer bug where it wasn't marking non-interface constraints as necessary. The C# unmanaged constraint is expressed as [modreq UnmanagedType] ValueType. We were not marking UnmanagedType as necessary.
4. Update checked in binder because this is a file format change
[tfs-changeset: 1708263]
|
|
Fixes #1194
|
|
|
|
|
|
Use results of whole program analysis to drive devirtualization
|
|
* Fix issues building the runtime, corelib and type loader for WebAssembly
* Fix test infrastructure to allow running with the wasm flavor
|
|
|
|
Test.CoreLib has bitrotted again.
|
|
IsByRefLikeAttribute is the shipping version of the StackOnlyAttribute
[tfs-changeset: 1664170]
|
|
- 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
|
|
VS is trying to "upgrate" the full framework projects without ToolsVersion
[tfs-changeset: 1662259]
|
|
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]
|
|
Building against the lightweight version of S.P.CoreLib has bitrotted
over the past year. The classlib is handy for codegen and architecture
bringups and we might want to use it when getting rid of ready to run
helpers.
|
|
* Add PreInitFieldInfo that extracts preinitialized data information from fields that have [PreInitialized] and [InitDataBlob] pointing to RVA field
* Added FrozenArrayNode for frozen arrays with data extracted from preinit RVA data field
* Added GCStaticsPreInitDataNode (CoreRT only) to hold GC pointers for GC static fields. Pre-init data fields points to frozen data, while other data initialized to null.
* Changed GCStaticsNode to emit a pointer reloc to GCStaticspreInitDataNode and mask 0x2 for the GC static EEType.
* Changed InitializedStatics in StartupCodeHelper to check for 0x2 and memcpy the GC field data as needed
* Fixed a bug in bad GCStaticsEETypeNode size calculation - it's off-by-1 as static GC static field layout in CoreRT includes EEType already.
|
|
The way we were setting common defines (such as `AMD64`, `BIT64`, `ARM`)
was extremely fragile and invited partial fixes such as #3414 and #3424.
This really needs to be centralized.
|
|
The class lib functions are already hooked up to code manager. However, there are cases where we look for class lib functions from EEtype, such as GetClasslibException on an eeype. This change attaches the class lib function array to every type manager and sets up a runtime helper to get to the class lib function GetRuntimeException from an EEtype.
[tfs-changeset: 1653592]
|
|
[tfs-changeset: 1652979]
|
|
* 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
|
|
between C++ and Managed
- Results in mishandling the parameters to the RhpGetModuleSection api
- Fix is to force a pointer to be passed, which has equivalent handling in both C++ and the existing managed calling convention on the windows x86 builds
[tfs-changeset: 1648927]
|
|
Merge nmirror to master
|
|
- Move from using an IntPtr which may represent a TypeManager* or a OS module pointer to using a struct TypeManagerHandle consistently
- Except for RuntimeSignature, which has a third possible meaning of its IntPtr. That work will be done in a seperate change, and wil result in removal of nearly all of the new TypeManagerHandle calls in this delta.
- This struct contains a bit which indicates which form of pointer is being worked with, as well as routines for performing RVA access as appropriate
- Added new api to redhawk to get the OS module list (Used in crash dump generation)
- Added new api to get the OS module of of a pointer. These are not yet enabled for TypeManager based scenarios, but that will be done in a followon change. Eventually these will exclusively be use for instruction pointers, and will tie into diagnostic scenarios around stack traces, etc. Currently, it is also used in a few reflection scenarios. Those code patterns will be removed soon.
- Similarly distinguished between getting the OS module for an EEType, and getting the module for an EEType. This is used in error message scenarios.
- Update RhFindBlob to work with both types of module pointers
[tfs-changeset: 1647831]
|
|
Building with Test.CoreLib bitrotted a bit. Fixing some of that.
* Frozen string literals need to declare their dependency on
`System.String` EEType
* We need *some* `AppendExceptionStackFrame`
Two more things remaining that I'm not fixing now:
* Interop marshalling codegen insists that `System.StringBuilder` needs
to exist in the class library
* We need to make building reflection support goo optional
|
|
Fixed issues and concerns from mirroring to Github
[tfs-changeset: 1647030]
|
|
[tfs-changeset: 1646943]
|
|
* Update CoreRT doc to include how to debug ILC using VSCode in non-windows
* Automate some of the tasks and check in vscode .json files
* Simplify instructions
* Explains the magic and added a bit more coding annotations to make it looks better
* Change ILCompiler.csproj to output ILC.dll directly to be VS-code friendly
|
|
Implement basic support for thread static fields
|
|
- 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/
|
|
This change implements basic support for thread static fields. Most things
are already functional, performance could definitely be improved in the
future but it should be sufficient to get things off the ground.
This code passes CoreRT and Top200 CoreCLR tests on Windows. The
BasicThreading test in this change verifies that thread static fields work
for both non-generic and generic types in the single-threaded and
multi-thread environment (using Tasks).
One thing that does not work yet is multi-module compilation because the
driver creates a separate ReadyToRun helper for a type in every module
that accesses thread statics of the type. I am currently working on fixing
this.
The existing code has already implemented a good chuck of required
functionality so this simply builds on top of that.
Each module has a ThreadStatic region. Each entry in the region points to
an EEType that represents a GC map for the thread static fields of a given
type. The index of the entry in the region is the TLS index of the type.
The TypeManager indirection node of the module has been extended to
contain the index of the module in addition to a pointer to the type
manager (which is also used for initialization on first access).
The generated ReadyToRun helpers (that return thread static base for a
type) look like this:
__GetThreadStaticBase_System_Private_CoreLib_System_Threading_ManagedThreadId:
48 8D 0D BD E0 39 00 lea rcx,[__typemanager_indirection
(07FF70D68AD58h)] <= module information (type manager, module index)
BA 03 00 00 00 mov edx,3 <= TLS index of the type
E9 33 FB E4 FF jmp
System_Private_CoreLib_Internal_Runtime_ThreadStatics__GetThreadStaticBaseForType
(07FF70D13C7D8h)
|
|
|
|
|
|
|
|
ifdefs (#1955)
|
|
|
|
This is a minimal core library for test purposes. It doesn't have
support for a broad range of features that people are used to (proper
class constructor support, reflection, glob/loc, etc), but on the other
hand lets you exercise various compiler features that would otherwise
not be very testable (because unless the feature is already fully
implemented, you won't be able to run enough code to get to your test).
It's largely based on stealing files from Runtime.Base and I think I
found a sustainable way to extend it as needed (with... drumroll...
partial classes).
* Update GUID for Runtime.Base project
Using the same GUID as System.Private.CoreLib was making it not unique
enough.
|
