- 25 8月, 2017 1 次提交
-
-
由 Mike Danes 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/ed9dc1f5173fa538de6c9fd9ec8d57399ff24497
-
- 24 8月, 2017 22 次提交
-
-
由 Carol Eidt 提交于
Fix improper handling of GenTreeAddrMode offset Commit migrated from https://github.com/dotnet/coreclr/commit/8e2d570c730419d2f8610a8d01b0a3e0da6cb29f
-
由 Carol Eidt 提交于
Fix ARM issues with Containment Commit migrated from https://github.com/dotnet/coreclr/commit/5bf1eeaac88b05f4f903a0db09b876035024e755
-
由 Mike Danes 提交于
For unknown reasons GenTreeAddrMode::gtOffset is unsigned rather than int. On 32 bit hosts this doesn't really matter but on 64 bit hosts we end up zero extending instead of sign extending it, GetTreeIndir::Offset() does that by casting from unsigned to size_t. It doesn't appear possible for this to cause correctness issues (because the address mode displacement is 32 bit anyway) but it's confusing and hurts CQ because the emitter can't recognize small negative displacements that can be encoded in a single byte. It's worth noting that CodeGen::genCreateAddrMode uses ssize_t internally to represent the offset but then returns it as unsigned the emitter works with either int or ssize_t displacements (e.g. emitIns_R_ARX & co. have int disp arguments, emitNewInstrAmd has ssize_t dsp argument). Change steps: Access GenTreeAddrMode's gtOffset via Offset() - Offset() returns the correct type - int instead of unsigned. All non-legacy uses of gtOffset were replaced with Offset() and casts were added where necessary. gtOffset was made private in non-legacy builds to ensure it is not used directly. Rename GenTreeIndir's Offset() to Address() - This function is problematic, it returns size_t which is suitable for representing addresses but not offsets. Rename it and then figure out where offsets are needed and where addresses are needed. Add back Offset() with the correct return type - All usages of GenTreeIndir::Address() (e.g. emitNewInstrAmd) expect ssize_t, not size_t. Fix the bug - GenTreeIndir::Offset() return ssize_t and GenTreeAddrMode::Offset() returns int. It doesn't make sense to have a cast to unsigned. Fix ARM's handling of GenTreeAddrMode offset - Various pieces of code (e.g. emitIns_valid_imm_for_ldst_offset) already treat the offset as signed, they use int, INT64, ssize_t. More importantly, emitarm64's emitInsLoadStoreOp treats the offset as signed while TreeNodeInfoInitIndir treates it as unsigned. The later is wrong. Commit migrated from https://github.com/dotnet/coreclr/commit/518e10bb494530cb1004b9bc44ad4d8da1c07b30
-
由 Mike McLaughlin 提交于
The createdump utility now enumerates all the native stack frames (with some help from the managed stack walker) for all the threads adding all the ELF unwind info needed. On a different machine and without any of the native modules loaded when the crashdump was generated all the thread stacks can still be unwound with lldb/gdb. Change the PAL_VirtualUnwindOutOfProc read memory adapter in DAC to add the memory to instances manager. Some misc. cleanup. Commit migrated from https://github.com/dotnet/coreclr/commit/94a67752ace5236cb6228c4cbc6e6c2976895f2a
-
由 Tijoy Tom 提交于
Revert incorrect change from commit 16fc300 Commit migrated from https://github.com/dotnet/coreclr/commit/a3e884a062607ac296fc3943796627e2209a95ea
-
由 Carol Eidt 提交于
These are changes that should have been part of PR dotnet/coreclr#13198: - Correctly contain struct arguments - Correctly get number of source registers - Clear register assignments on `GT_FIELD_LIST` nodes (thanks @hseok-oh). - Remove now-redundant `ContainCheck` methods for armarch targets. Commit migrated from https://github.com/dotnet/coreclr/commit/5495b89a1368ecb279f2d1b39e69fdab96b9faa4
-
由 Pat Gavlin 提交于
Type `lea [this + delegateObject]` as `TYP_BYREF`. Commit migrated from https://github.com/dotnet/coreclr/commit/90d0a3e00eab850b2bac5e685a6ce2aba96f290f
-
由 William Godbe 提交于
Parameterize RIDs for package restore Commit migrated from https://github.com/dotnet/coreclr/commit/c486926a6a85bb61e516f69e900812d3294e69a0
-
由 Noah Falk 提交于
Add more logging to corefx test CI runs Commit migrated from https://github.com/dotnet/coreclr/commit/dac0a16bbc7fa9f3ceb1181c208ca27a9777678d
-
由 noahfalk 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/5c5830c5b64e132c136401ade41b8d9748fa3915
-
由 Roman Artemev 提交于
Revert "Fixed misconception between FP register allocator and RyuJIT's CSE phase" Commit migrated from https://github.com/dotnet/coreclr/commit/2cb3585470b973fda3ba950e295cc3e936a71cde
-
由 William Godbe 提交于
Disable default BuildNumberMajor Commit migrated from https://github.com/dotnet/coreclr/commit/6aed5a155a60aafa591a7d9bbe9864074469f54a
-
由 tijoytk 提交于
https://github.com/dotnet/coreclr/commit/dotnet/coreclr@16fc3005c085212f6e700a0df8ff7f36c1ea535b The PR was trying to fix an incorrect test , we should be passing in !fForWinRT.See https://github.com/dotnet/coreclr/issues/13460#issuecomment-324456870 for more info. Commit migrated from https://github.com/dotnet/coreclr/commit/3d777c6b864dfdbde9db823ccdc27f087725f45c
-
由 Jim Ma 提交于
Other than `ContainsPointers` and `IsNotTightlyPacked`, added two new conditions for checking whether a valuetype can go to fast path or not. Following are the details of these 2 conditions: - Check whether a valuetype contains a Single/Double field. If it does, we cannot go to fast path. Floating point numbers have special `Equals` and `GetHashCode` implementation. We cannot simply compare floating point numbers via bits (e.g. +0.0 should equal to -0.0, but their underlying bits are different). - Check whether an user-defined valuetype overrides `Equals` or `GetHashCode`. If it does, we cannot go to fast path. Because `Equals` or `GetHashCode` result may be different to bit comparison. To find Single/Double fields and overridden `Equals`/`GetHashCode`, we start a DFS to go through the whole hierachy of the source valuetype, and cache the result to `MethodTable`. Fix dotnet/coreclr#11452 Commit migrated from https://github.com/dotnet/coreclr/commit/495ece4abd2204e1fc79f34cf3ea7fe5ecf90ad3
-
由 Pat Gavlin 提交于
This node was incorrectly typed as `TYP_GCREF`, which was causing an assertion during GC stress in internal testing. Fixes VSO 482577. Commit migrated from https://github.com/dotnet/coreclr/commit/6025fd00f0c86359817d5b09470120c177e4a124
-
由 wtgodbe 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/6c0e0abf7c7b2ab48671ec2e37ff925fb5ca9c80
-
由 Roman Artemev 提交于
This reverts commit dotnet/coreclr@3f4ee3bed52291e592d7ab67da1fc0e39ee8a3b7. Commit migrated from https://github.com/dotnet/coreclr/commit/81c38cd7272d0cbb70885122b7350fedaf0fd3ba
-
由 Brian Sullivan 提交于
Merge changes from TFS Commit migrated from https://github.com/dotnet/coreclr/commit/59da8574383d547a20dcae478b67ff458f6d71e6
-
由 Koundinya Veluri 提交于
* Improve ReaderWriterLockSlim scalability Subset of dotnet/coreclr#13243, fixes dotnet/coreclr#12780 - Prevented waking more than one waiter when only one of them may acquire the lock - Limited spinning in some cases where it is very unlikely that spinning would help The _myLock spin lock runs into some bad scalability issues. For example: 1. Readers can starve writers for an unreasonable amount of time. Typically there would be more readers than writers, and it doesn't take many readers to starve a writer. On my machine with 6 cores (12 logical processors with hyperthreading), 6 to 16 reader threads attempting to acquire the spin lock to acquire or release a read lock can starve one writer thread from acquiring the spin lock for several or many seconds. The issue magnifies with more reader threads. 2. Readers and especially writers that hold the RW lock can be starved from even releasing their lock. Releasing an RW lock requires acquiring the spin lock, so releasers are easliy starved by acquirers. How badly they are starved depends on how many acquirers there are, and it doesn't take many to show a very noticeable scalability issue. Often, these acquirers are those that would not be able to acquire the RW lock until one or more releasers release their lock, so the acquirers effectively starve themselves. This PR does not solve (1), but solves (2) to a degree that could be considered sufficient. dotnet/coreclr#13243 solves (1) and (2) and for (2) it is still better by order-of-magnitude compared with this PR in several cases that I believe are not extreme, but if the complexity of deprioritization is deemed excessive for the goals then of what I tried so far this is the perhaps simplest and most reasonable way to solve (2). I believe this PR would also be a reasonably low-risk one to port back to .NET Framework. Commit migrated from https://github.com/dotnet/coreclr/commit/e000977dc11feb3f7f7920a57f0e53f4749377e0
-
由 Jan Vorlicek 提交于
Alpine Linux has a very small default stack size limit, about 80kB. This is not enough for running coreclr apps. This change enables overriding the default stack size using the COMPlus_DefaultStackSize env variable. For Alpine, it also sets the default stack size to the same value we use for Windows, which is 1.5MB. Commit migrated from https://github.com/dotnet/coreclr/commit/5f2d1ec0e50a3aceddcc75172021cea10677b354
-
由 Bruce Forstall 提交于
[RyuJIT/arm32] Fix MultiReg flag setter Commit migrated from https://github.com/dotnet/coreclr/commit/8abfe25cbd02e07361301e0a5cadb6716b3c0cde
-
由 Andy Ayers 提交于
The jit will refine the types of temps used to pass arguments to inlinees when it creates the assignments to these temps. Unfortunately this is too late to drive devirtualization in the body of the inlinee, as thes assignments are created after the inlinee body is imported. So, add similar refinement logic to the place where the temps are first created. Closes dotnet/coreclr#13520. Commit migrated from https://github.com/dotnet/coreclr/commit/85c59f9aa92092e72618df51879a9338ca9d4307
-
- 23 8月, 2017 17 次提交
-
-
由 Jonghyun Park 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/f46134f56e408fc3e4cd14cd8ed43be90765f7fe
-
由 Carol Eidt 提交于
[RyuJIT/ARM32] Remove unnecessary genIsValidDoubleReg() assertion Commit migrated from https://github.com/dotnet/coreclr/commit/6fe0e8685e81099f5e1cf02504ddfe4ff183c750
-
由 Joseph Tremoulet 提交于
Add InnerIterationCount to layout benchmarks Commit migrated from https://github.com/dotnet/coreclr/commit/c8ede5ad70ffa3bc34a522102b7646cae2bdebfd
-
由 Hanjoung Lee 提交于
Bitwise operation fix in `SetRegSpillFlagByIdx()`. Fix dotnet/coreclr#13423 Commit migrated from https://github.com/dotnet/coreclr/commit/7447d75d3027c4d01171ea46753d371fe7835a61
-
由 Stephen Toub 提交于
When I added the base Stream.Read/Write(span) default implementations, I added a special-case check for if the span is empty, in which case it made the operation a nop. But various streams want to impose behavior even in the 0-byte case, e.g. throwing an ObjectDisposedException if the stream has been closed. This commit just removes the check and allows Read/Write to delegate for all sized spans. Commit migrated from https://github.com/dotnet/coreclr/commit/a9c4c6c6f85a26591c72983ea28eccb581eb9eca
-
由 Roman Artemev 提交于
Fixed assertion failure in legacy backend Commit migrated from https://github.com/dotnet/coreclr/commit/463a67316ef0187373a6d4c501aa913026ab6d88
-
由 Stephen Toub 提交于
Override Span-based Read/Write on FileStream Commit migrated from https://github.com/dotnet/coreclr/commit/fa79179baa11923cba48e2cdd9c9bd723486a136
-
由 Roman Artemev 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/a88ac369ee776acafcaf1a39aeee93520b07b5f0
-
由 Andy Ayers 提交于
Modify gtNewTempAssign to more generally map self-assignment of temps into nops. We already were doing something similar over in `impAssignStruct`, and now we catch non-struct cases too. Commit migrated from https://github.com/dotnet/coreclr/commit/637bfeffb0fd0378ff6d04d7bb845938b77bdade
-
由 dotnet-bot 提交于
[tfs-changeset: 1671421] Commit migrated from https://github.com/dotnet/coreclr/commit/fd9dce46c1d441883bb38ca24554ce3f8224276e
-
由 dotnet-bot 提交于
[tfs-changeset: 1671419] Commit migrated from https://github.com/dotnet/coreclr/commit/5f0700214606bb9d922e686d9cca0c489379202d
-
由 wtgodbe 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/faa15fee64e8b702a4212e8081087ebcaa458fae
-
由 Sean Gillespie 提交于
Remove macro definition checks that aren't useful and cause unnecessary build breaks (dotnet/coreclr#13523) Commit migrated from https://github.com/dotnet/coreclr/commit/1eea080a7b3a13110975b92034a22e4fc473df46
-
由 Jonghyun Park 提交于
Commit migrated from https://github.com/dotnet/coreclr/commit/8b7dcb5900392f9e30a8aaabe11c89d470178322
-
由 Joseph Tremoulet 提交于
These tests were too short-running to measure effectively. Add an inner iteration count that makes the running time around 1 second (measured locally). Commit migrated from https://github.com/dotnet/coreclr/commit/ad75eead4d663427381c103246c27c2e20587420
-
由 Jonghyun Park 提交于
* Introduce COMPlus_GDBJitEmitDebugFrame * Use a proper #ifdef macro Commit migrated from https://github.com/dotnet/coreclr/commit/aed0665893b812eadd8be6362116285f59e27288
-
由 Stephen Toub 提交于
Adds overrides for the new Span-based Read/Write methods on FileStream. A few notes: - As with {Unmanaged}MemoryStream, FileStream isn't sealed, which means a derived type could have overridden all of the existing abstract/virtual methods, including Read(byte[],int,int). If a consumer then switched to using that stream with Read(Span), because we now override Read(Span), the consumer should get the same behavior intended by the stream developer. As such, since we have no good/efficient way to check whether Read(byte[],int,int) is overridden, we check whether the current stream is a concrete FileStream (rather than a derived type), and if it isn't we use the default base behavior, which will call the Read(byte[],int,int) method. - FileStream is odd in that it has a dual nature around whether it was initialized for sync vs async, a setting that on Windows ends up configuring the native handle to operate in async mode. Sync operations on an async-configured FileStream end up delegating to the async methods and blocking, and async operations on a sync-configured FileStream end up using the synchronous behavior asynchronously. There were some inconsistencies around how this was handled between Windows and Unix, in particular around the ReadByte method, and as part of adding these overloads, I changed that as well, as doing so made the code simpler with the new Span-based support. Technically this is a breaking change on Unix, but it would be very niche, including calling ReadByte on an async stream while other async operations were in progress... in that case, the desktop and Windows core behavior was to allow direct access to any cached data in the buffer, whereas on Unix we would serialize the ReadByte call with other async operations in flight. Commit migrated from https://github.com/dotnet/coreclr/commit/1cb3580858f3224f0e0981965a2da1fd61ba9e08
-