Hi gcc-patches mailing list, Christopher Bazley via Sourceware Forge <[email protected]> has requested that the following forgejo pull request be published on the mailing list.
Created on: 2026-07-29 20:51:39+00:00 Latest update: 2026-07-29 20:51:39+00:00 Changes: 3 changed files, 61 additions, 3 deletions Head revision: chris.bazley/gcc ref strb commit 2705baac96c83fddcc2f9dca6bb541b94d6a6e27 Base revision: gcc/gcc ref trunk commit b80a4347fc63b1a6ed6e2b3ea26c5948f08ba3cd r17-2748-gb80a4347fc63b1 Merge base: b80a4347fc63b1a6ed6e2b3ea26c5948f08ba3cd Full diff url: https://forge.sourceware.org/gcc/gcc/pulls/205.diff Discussion: https://forge.sourceware.org/gcc/gcc/pulls/205 Requested Reviewers: PR target/126480 The following pattern of truncating assignments whose results are consumed only by store operations is relatively common: dst[0] = (unsigned char) src[0]; dst[1] = (unsigned char) src[1]; .... dst[N] = (unsigned char) src[N]; Prior to this change, the vectorizer estimated unrealistically high costs for some scalar code: a cost was charged for each narrowing conversion, even though those conversions are effectively free as part of the associated stores. Consequently, the vectorizer could decide to vectorize code that should not have been vectorized. Scalar costs are inevitably somewhat overestimated in the case of byte order reversals that should cause GCC to generate a 'rev' instruction, because the vectorizer estimates costs independently of the store-merging pass that discovers such reversals in scalar code. When predicated tails are enabled for basic block SLP, the scalar cost of reversals can be overestimated by so much that they are vectorized. That will not happen after this change is applied. The AArch64 backend now uses a new vectorizer function, vect_is_truncating_store, to tell whether a given stmt truncates the input of a store. This function is analogous to an existing function, vect_is_extending_load, which tells whether a given stmt extends the result of a load. The two functions are called in roughly the same places, to help with the accuracy of costing scalar and vector stmts. A truncating assignment that has multiple uses should not be in an SLP tree being costed, but it seems convenient to use single_imm_use anyway (and it fits the expected/desired case we need to identify). gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_detect_scalar_stmt_subtype): Call the new vect_is_truncating_store function and return 0 if vect_is_truncating_store returns true. (aarch64_sve_adjust_stmt_cost): Call vect_is_truncating_store and assign 0 to stmt_cost if vect_is_truncating_store returns true. * tree-vectorizer.h (vect_is_truncating_store): New function analogous to vect_is_extending_load. gcc/testsuite/ChangeLog: * gcc.target/aarch64/pr126480.c: New test. Changed files: - A: gcc/testsuite/gcc.target/aarch64/pr126480.c - M: gcc/config/aarch64/aarch64.cc - M: gcc/tree-vectorizer.h Christopher Bazley (1): AArch64: Improve costing of truncated stores gcc/config/aarch64/aarch64.cc | 16 +++++++++--- gcc/testsuite/gcc.target/aarch64/pr126480.c | 19 ++++++++++++++ gcc/tree-vectorizer.h | 29 +++++++++++++++++++++ 3 files changed, 61 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/gcc.target/aarch64/pr126480.c -- 2.54.0
