[Bug target/110625] [14 Regression][AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:984bdeaa39b6417b11736b2c167ef82119e272dc

commit r14-6865-g984bdeaa39b6417b11736b2c167ef82119e272dc
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Dec 29 15:58:29 2023 +0000

    AArch64: Update costing for vector conversions [PR110625]

    In gimple the operation

    short _8;
    double _9;
    _9 = (double) _8;

    denotes two operations on AArch64.  First we have to widen from short to
    long and then convert this integer to a double.

    Currently however we only count the widen/truncate operations:

    (double) _5 6 times vec_promote_demote costs 12 in body
    (double) _5 12 times vec_promote_demote costs 24 in body

    but not the actual conversion operation, which needs an additional 12
    instructions in the attached testcase.   Without this the attached testcase
ends
    up incorrectly thinking that it's beneficial to vectorize the loop at a
very
    high VF = 8 (4x unrolled).

    Because we can't change the mid-end to account for this the costing code in
the
    backend now keeps track of whether the previous operation was a
    promotion/demotion and ajdusts the expected number of instructions to:

    1. If it's the first FLOAT_EXPR and the precision of the lhs and rhs are
       different, double it, since we need to convert and promote.
    2. If it's the previous operation was a demonition/promotion then reduce
the
       cost of the current operation by the amount we added extra in the last.

    with the patch we get:

    (double) _5 6 times vec_promote_demote costs 24 in body
    (double) _5 12 times vec_promote_demote costs 36 in body

    which correctly accounts for 30 operations.

    This fixes the 16% regression in imagick in SPECCPU 2017 reported on
Neoverse N2
    and using the new generic Armv9-a cost model.

    gcc/ChangeLog:

            PR target/110625
            * config/aarch64/aarch64.cc (aarch64_vector_costs::add_stmt_cost):
            Adjust throughput and latency calculations for vector conversions.
            (class aarch64_vector_costs): Add m_num_last_promote_demote.

    gcc/testsuite/ChangeLog:

            PR target/110625
            * gcc.target/aarch64/pr110625_4.c: New test.
            * gcc.target/aarch64/sve/unpack_fcvt_signed_1.c: Add
            --param aarch64-sve-compare-costs=0.
            * gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c: Likewise