[Bug rtl-optimization/126426] riscv rvv: Incorrect result with -march=rva23u64 -O2 in libgav1

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:090baea02d768ff884d1b326d6bf7d57cfcc1231

commit r17-3273-g090baea02d768ff884d1b326d6bf7d57cfcc1231
Author: Jeff Law <jeffrey.law@oss.qualcomm.com>
Date:   Thu Aug 13 18:34:48 2026 -0600

    [PR rtl-optimization/126426] Handle vector mode uses conservatively in
ext-dce

    So ext-dce isn't terribly vector aware, it mostly tries to stay out of the
way
    and stay conservatively correct when vector modes are encountered.

    When that code was added in 2023/2024 it goofed a very important case that
has
    now reared its ugly head.

    Consider a use of V2HI.  What bits are live as a result of such a use? 
Right
    now we record 0xffff as the bits potentially live.  But that's badly wrong.
 We
    have 2 HI objects, so there's actually 32 bits of live data, so 0xffffffff.

    With the bits live being incorrect we can incorrectly remove an extension
    because we think the bits are never read.  That's precisely what happens in
    this PR.

    Not much motivation was given for using GET_MODE_INNER rather than GET_MODE
    other than it works better for vector/complex.  I should have caught this
when
    it was introduced.

    For a destination, GET_MODE_INNER is safe.  The worst case is we'll fail to
    mark bits as dead which in turn will inhibit optimization.  For a source
    operand it's a completely different story.  By failing to mark some bits as
    live we can (as this pr showed) erroneously remove an extension.

    While reviewing all the uses of GET_MODE_INNER, I've become convinced the
    vector handling in carry_backpropagate is broken.  If it's going to support
    vector, it needs to do what it's doing now with the GET_MODE_INNER stuff
which
    gives us liveness of an element, then broadcast the liveness state across
all
    the elements of the vector.  It seems like it should be possible to support
    this case, but having not seen anything even close to it in practice, I'm
    punting it for now and returning a conservatively correct state when
presented
    with vector modes in carry_backpropagate.

    This has been bootstrapped and regression tested on riscv64, x86_64,
aarch64,
    alpha, hppa and others.  It's also been tested without regressions on the
    various *-elf targets.  Pushing to the trunk.

            PR rtl-optimization/126426

    gcc/
            * ext-dce.cc (carry_backpropagate): Return a conservatively
            correct mask when presented with vector modes.
            (ext_dce_process_uses): Don't use GET_MODE_INNER, we need to
            know the full extent of the bits for vector and complex modes.

    gcc/testsuite
            * gcc.target/riscv/pr126426.c: New test.