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.
