[Bug target/122448] [15 Regression] Wrong rvv code with -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-15 branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:1ac88858e4d47b397698a6db6a860851c8fa76ff

commit r15-10931-g1ac88858e4d47b397698a6db6a860851c8fa76ff
Author: Robin Dapp <rdapp@oss.qualcomm.com>
Date:   Thu Feb 19 15:44:38 2026 +0100

    RISC-V: Consider uses for vsetvl LCM transparency. [PR122448]

    Until now we didn't consider (pre-existing) uses of vsetvl's destination
    registers when computing transparency for vsetvl LCM.  In rare instances,
    this can lead to hoisting vsetvls beyond blocks that have uses on such
    registers.

    We already check transparency when hoisting but here LCM computes edge
    insertion points.

    For vsetvl a5,zero,e16,m1 in BB 65 we have the following, not
    particularly uncommon, situation:

                    BB 63
                     |  \
                     |   \
                     |    \
                     v     |
                    BB 64  |
                     |     |
                     |    /
                     |   /
                     | /
                     v
                    BB 65

    BB 64 uses a5, so is not transparent with respect to the vsetvl.
    BB 63 -> BB 65 is an edge LCM computes as earliest.
    But we're not inserting the vsetvl on just that edge like in regular LCM
    where we could have a new block along that edge but instead insert it at
    the end of BB 63.  At that point, though, the other outgoing edges and
    successor blocks have to be considered as well.

    The patch is two-fold.  It adds a new bitmap m_reg_use_loc that keeps
    track of uses of vsetvl destinations, rather than just new definitions
    and adds them to the transparency bitmap.  This correct LCM's
    computations with respect to uses.  Then, as described above, it
    prevents hoisting into the target block (BB 63) if the vsetvl's
    destination register is used outside of vsetvls in any other
    successor (BB 64).

    In regular, non-speculating LCM we would be able to just check ANTOUT but
    as we are hoisting speculatively this won't work.  We don't require all
    successors to have a vsetvl in order to hoist it to a block.
    Therefore the patch computes reaching definitions for all vsetvl's
    destination registers up to their AVL uses.  Knowing a block's live-in
    and the reaching definitions we can deduce that a use must be non-vsetvl
    and prone to clobbering.

            PR target/122448

    gcc/ChangeLog:

            * config/riscv/riscv-vsetvl.cc (compute_reaching_defintion):
            Rename...
            (compute_reaching_definition): ...To this.
            (pre_vsetvl::compute_vsetvl_def_data):  Compute reaching
            definitions for vsetvl VL -> vsetvl AVL.
            (pre_vsetvl::compute_transparent): Include VL uses.
            (pre_vsetvl::fuse_local_vsetvl_info): Initialize m_reg_use_loc.
            (pre_vsetvl::earliest_fuse_vsetvl_info): Don't hoist if any
            successor would use VL.

    gcc/testsuite/ChangeLog:

            * g++.target/riscv/rvv/base/pr122448.C: New test.

    (cherry picked from commit 0635bfb53a145cc005a15657635abf8ea9e6e9ba)