Improve SequenceEqual for constant lengths unrolling#84524
Improve SequenceEqual for constant lengths unrolling#84524stephentoub merged 1 commit intodotnet:mainfrom
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-memory Issue DetailsSlightly improve After this PR, e.g. TryGetFloatingPointConstant is fully unrolled (all three
|
src/libraries/System.Private.CoreLib/src/System/MemoryExtensions.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/MemoryExtensions.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/MemoryExtensions.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/MemoryExtensions.cs
Outdated
Show resolved
Hide resolved
|
@EgorBo In theory, the length in |
8d89753 to
3cfb576
Compare
|
@xtqqczze thanks for suggestion but in this case I'm interesting in making Current diffs: This PR triggered 23 new unrollings. |
|
@stephentoub any thoughts on this? it triggered 23 new unrollings but in theory jit should be able to handle both patterns, but that will need quite some extra efforts |
|
I'm fine with it if it doesn't regress anything meaningfully. |
@stephentoub It should not (on all runtimes) and number of new unrollings prove it's better to speculate that "other.Length" is likely to be constant. Can you apporve it? 🙂 I needed it for #84525 |
Slightly improve
MemoryExtensions.SequenceEqualshape to expose more "constant length" cases for unrolling. It's a JIT phase ordering issue, in theory, if we run VN again after Assert prop we'll do the same in JIT, unfortunately, JIT's logic to run some phases more than once is currently broken.After this PR, e.g. TryGetFloatingPointConstant is fully unrolled (all three
SequenceEqualin it)