https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126480

--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Christopher Bazley <[email protected]>:

https://gcc.gnu.org/g:10c43486134d6a64e941fc758f2aa20008b43190

commit r17-2819-g10c43486134d6a64e941fc758f2aa20008b43190
Author: Christopher Bazley <[email protected]>
Date:   Wed Jul 29 14:25:13 2026 +0000

    AArch64: Improve costing of truncated stores

    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.

Reply via email to