Sync to Head #1
Merged
Sync to Head #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#7913 brought in an odd change.
* fix unsigned extend to uint64 and add test * remove debug documentation that no longer applies now that js output, WASM=0, is not supported. * boxing singles fix * Adds a test for boxing a float32 into a single and the fix * remove variable
Port dotnet/coreclr#27048 to CoreRT PAL Fixes #7927
Also fix cmake warning about unused variable by conditionally including it.
* Separation of ExportsFile formats for OSX and Linux. * Simplification of ExportsFileExt condition. * Same extension for version-script (Linux) and Exported-Symbols-List (OSX). * Separation of version-script fixes and size file reduction changes.
Mostly taken from the cpp backend, this enables shared generics and generic virtual methods for the Wasm backend. Have tried to keep the logic as clean as I could, but maybe there's some obvious enhancements/reductions in code that I missed. Size of HelloWasm.bc (LLVM bitcode) before 43,950KB, and after 37,593KB (these aren't exact as the after includes more tests, so actual saving is probably fractionally better) . HelloWasm before this change didn't have much in the way of generics so this mostly reflects the framework and runtime generics. Enables the Simple/Generics tests for wasm which have the almost same coverage as cpp (Wasm includes an additional test) in terms of what is #if'ed out.
Previously this was doing a sign extension resulting in left filling with the MSB of the UInt16. This change adds a test for this and fixes it.
This step has been failing for months. It's a nuisance because it also makes the official build show as failed. All we care about is publishing NuGet packages and that happens before this step.
* Fix x86 Windows build * Fix calling convention mismatch in JitHost * Fix ObjWriter build * Fix ObjWriter calling convention mismatch * Use the correct target triple for x86 * Implement helper to get the non-GC static base * Implement helpers necessary to get a build out
VEH may use the runtime instance
clang-3.9 is not available on recent Linux distros. Typically, there is clang alias setup for a good version of clang so just use that by default. Fixes #5654
* The called methods accept a byref, not a pointer. * The called methods don't return anything. This is also a slight perf improvement (no longer need to allocate the lambda for `PinObjectAndCall`). Fixes #7951.
…bug that blows up
The common JitInterface cannot depend on ILCompiler namespace.
The template parameters are specified for the template class. Redeclaring them here is not allowed.
Also, add a sanity check to the build targets to make this mistake easier to diagnose.
• Change FieldLayoutAlgorithm.ComputeValueTypeShapeCharacteristics method to compute the homogeneous aggregate element type and cache it in the existing field. That allows to remove all ComputeHomogeneousFloatAggregateElementType methods. • Change MetadataFieldLayoutAlgorithm.ComputeHomogeneousAggregateCharacteristic to compute HVAs in addition to HFAs. • Change CorInfoImpl.getHFAType JIT callback to handle HVAs. Note that returning ELEMENT_TYPE_VALUETYPE indicates the TYP_SIMD16 type (see Compiler::GetHfaType).
In an earlier change I also added the `type.Instantiation[0].IsPrimitive` condition to the `IsVectorType` predicate. Revert that part as well and allow only primitive numeric types for HFA/HVA purpose.
The RD.XML format CoreRT uses is different from .NET Native, so this probably causes more harm than good.
AllocAndTransform is not called for out/ref marshalling, so this was ending up blitting the raw pointer across.
Seems like a VS update broke the CoreFX legs. We reinitialize the VS environment a lot.
The purpose of the thunk was to prevent invoking methods pointing to `UnmanagedCallersOnly` methods. We're going to let that happen and hope that triggering the reverse p/invoke transition when we're still in managed mode is going to failfast instead. This is a mild size saving as well.
This extends the static constructor interpreter with support for preinitializing delegates and support for reading readonly static fields declared by other types. The readonly static fields can be accessed after interpreting the static constructor of the containing type. This opens us up to recursive dependencies. The interpreter will bail if recursive dependency is hit (we already have a test). This significantly improves the interpreter's ability to run static constructors at compile time: | | Eligible types | Preinitialized before | Preinitialized after | | -------- | -------------- | --------------------- | -------------------- | | WinForms | 1520 | 702 | 967 | | WebApi | 2005 | 746 | 1278 | About 60% of types now have their static constructor executed at compile time.
If the data is all zeros, we can place it in the uninitialized data region. No point storing zeros in the executable.
Reflection-accessing threadstatic fields didn't work. I'm also deleting a bunch of .NET Native code that is not relevant to CoreRT. The .NET Native approach to threadstatics (using TLS region) is Windows-specific and not portable. The type loader support is incomplete (the compiler side is ready but runtime side is still going to fail with a MissingTemplateException). I got tired and this diff is already too big. Contributes to #5137.
The original reason why these were split is to make it possible to share the writer with the .NET Native compiler. This is no longer needed.
From a quick search in the LLVM codebase, the only thing this controls is whether to generate a timestamp into the object file in PE/COFF outputs. This breaks output determinism. We disable incremental linking anyway: https://github.com/dotnet/corert/blob/692e443e3427e43f54b0e43567d7df761a47c961/src/BuildIntegration/Microsoft.NETCore.Native.Windows.props#L72-L73
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.