Rollup of 23 pull requests#158991
Conversation
This is just more helpful for knowing what all needs to be fixed when CI fails.
Replacing `iter_specializations` (which repeatedly invokes a callback) with an iterator implementation allows `Itertools::format_with` to be used more broadly, which in turn allows disparate string interpolation to be combined and hopefully provide greater context to the reader.
Updates `get_load_function` to return `svld{n}_{ty}` when loading a
scalable vector type. Caller of `get_load_function` will still need
updated to handle passing the predicate arguments to these load
functions.
Updates the headers used by generated C code and the target feature flags passed to the C compiler to enable SVE.
Some SVE intrinsics take booleans as arguments, so there is a need to support generating a test value array for booleans.
Constraints that correspond to enum types - such as `svpattern` and `svprfop` - need to be converted to the enum type in order to be used in a generic instantiation - so introduce a const function for both types that provides this mapping.
Predicate arguments of type `svbool_t` do not need test value arrays to be generated as the same enable-all-lanes predicate will be passed to all invocations of the intrinsic under test. There is no `svld1` equivalent for `svbool_t` that could be used even if there were test values to use.
Support defining a local variable containing the predicate that will be used with all subsequent scalable vector intrinsics.
Implementation of `get_comparison_function` and `get_predicate_function` for SVE which uses the relevant SVE intrinsics.
Instead of assuming that any scalable boolean argument is a predicate, handle predicates specifically and generate test values for `svbool_t` values.
SVE isn't a baseline target feature for `aarch64-unknown-linux-gnu` but should be enabled when running tests.
Like with non-SVE test generation, comparison of float results in scalable vectors need special-handling of comparisons.
Enables generation of tests for SVE intrinsics leveraging the changes from the previous commits.
This makes it far easier to debug what's potentially gone wrong with an intrinsic test.
Same as previous redefinitions in stdarch#2163 - these were missed in that PR because the hardware being tested on was missing the hardware feature required for the instructions these use.
intrinsic-test: sve support
Replace cfg_if with cfg_select
loongarch: Use `intrinsics::simd` for v{ld,st}[x]
Merge stdarch-gen-hexagon-scalar into stdarch-gen-hexagon
loongarch: Use `intrinsics::simd` for vrotr[i]
loongarch: Use `intrinsics::simd` for vfrecip
|
@bors r+ rollup=never p=5 |
|
@bors try jobs=dist-various-1,test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple,x86_64-mingw-1,i686-msvc-* |
This comment has been minimized.
This comment has been minimized.
Rollup of 23 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-*
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 07074cf (parent) -> 561ea2b (this PR) Test differencesShow 932 test diffsStage 1
Stage 2
Additionally, 890 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 561ea2bfa3022226082e2db39d6ccb241e9e34bc --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
📌 Perf builds for each rolled up PR:
previous master: 07074cfe1d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (561ea2b): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.2%, secondary -4.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.6%, secondary 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 489.352s -> 489.147s (-0.04%) |
Successful merges:
--output-format=jsoncoverage and ir differently #154445 (rustdoc: Represent--output-format=jsoncoverage and ir differently)b_offsetinsideBackendRepr::ScalarPair#158666 (Carry theb_offsetinsideBackendRepr::ScalarPair)-Zforce-intrinsic-fallback#158927 (add core test run with-Zforce-intrinsic-fallback)x perf compare#158932 (Do not build the compiler when invokingx perf compare)__main_argc_argv#158937 (Emit the emscripten entry point as__main_argc_argv)VecDeque::retain_backfromtruncate_front#151379 (StabilizeVecDeque::retain_backfromtruncate_front)Vec::dedup_bydocs explicit function argument order #157995 (Vec::dedup_bydocs explicit function argument order)Option::into_flat_itersignature #158741 (SimplifyOption::into_flat_itersignature)browser-ui-testversion to0.24.1#158913 (Updatebrowser-ui-testversion to0.24.1)r? @ghost
Create a similar rollup