[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

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

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

Robin Dapp <rdapp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
This one is really a bit tricky.

We have the following situation:

loop:
<bb 3>
# vectp_g.178_1078 = PHI <vectp_g.178_1079(3), &gD.2750(2)> 
_911 = &MEM... vectp_g.178_1078
MASK_LEN_LOAD (_911, ...);
vectp_g.178_1079 = vectp_g.178_1078 + 16;
goto loop;

<bb 4>:
MASK_LEN_LOAD (_911, ...);

During expand we basically convert back the _911 to vectp_g.178_1078 (reverting
what we did in ivopts before).  Because _911 camouflages vectp_g.178_1078 until
expand we evaded the conflict checks of outof-ssa that would catch a similar,
non-camouflaged situation like:

# vectp_g.178_1078 = PHI <vectp_g.178_1079(3), &gD.2750(2)> 
MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...);
vectp_g.178_1079 = vectp_g.178_1078 + 16;
goto loop;
MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...);

and would insert a copy of the definition right before the backedge.  The
MASK_LEN_LOAD after the loop would then use that copy.  By using _911 instead
of the original pointer no conflict is detected and we wrongly use the
incremented pointer.  Without the ivopt change for TARGET_MEM_REF

Unless I'm misunderstanding some basic mechanism it's not going to work like
that (and we could also have this situation on aarch64).  What could help is to
enhance trivially_conflicts_p in outof-ssa to catch such TARGET_MEM_REFs here
and handle them similarly to a normal conflict.  I did that locally and it
helps for this particular case but I'd rather not post it in its current hacky
state even if the riscv testsuite looks ok :)  Even if that were the correct
solution I'd doubt it should land in stage 4.

CC'ing Richard Sandiford as he originally introduced the ivopts and expand
handling.