Respect custom strides in scalar compound assignment - #2939
CAOShurong wants to merge 1 commit into
Conversation
Sorry, something went wrong.
Merging this PR will degrade performance by 18.92%⚠️ 1 benchmark measured no execution time
❌ 1 regressed benchmark Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent. Comparing CAOShurong:codex/fix-strided-scalar-assignment (821ea73) with master (8e14e7b) |
Sorry, something went wrong.
|
I investigated the shape benchmark using the reported base 8e14e7b and head 821ea73, GCC 13.3, and CodSpeed runner 4.19.1. Reproducer and raw profiles. The shape translation unit has identical dependencies and disassembly, and does not include the changed xassign.hpp. Both builds execute 21 instructions, 6 reads and 3 writes for svector; the head has one additional simulated instruction-cache miss (3 vs 2). Relinking the same objects with the shape object first gives it the same address in both binaries, and all four shape benchmarks then have identical counters. This points to code-placement sensitivity in the simulation. The PR code is unchanged. Could you assess whether this CodSpeed result can be acknowledged? |
Sorry, something went wrong.
Checklist
Description
Fixes #2773.
Scalar compound assignment currently writes the storage prefix even when an adaptor has padded strides. Use logical iteration for non-dense strides, while preserving physical iteration for dense layouts, including custom axis permutations. Dense-layout traversal preserves the behavior of aliased scalars and stateful, noncopyable functors.
Tests cover padded rows and columns, empty adaptors, scalar aliasing and functor state for both dynamic- and fixed-rank adaptors.
Validation: 26 adaptor cases (114 assertions), installed CMake consumers, and 224 owned-buffer checks under AddressSanitizer passed. A partial broader run passed 1,219 cases from the 77 test modules that compile on MSVC 19.42; the full build encounters the same baseline errors in test_xfunction and test_xvectorize.
Local microbenchmarks found up to ~1.7 ns overhead for 16-element arrays; large-array candidate/baseline ratios reached 1.13x. Linux and macOS validation remains to CI.