https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123806
Robin Dapp <rdapp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdapp at gcc dot gnu.org
Last reconfirmed| |2026-1-24
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=122869
--- Comment #1 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I find it difficult to read the code with those VLA spills... Luckily the test
also fails with -mrvv-vector-bits=zvl. And that version is much more legible.
My suspicion is that a my FoF fix wasn't sufficient as I modeled it as just a
regular FoF load and an RTL pattern that reads VL (to make the dependency
obvious). But we have the exact same problem again, a spill to memory requires
a vsetvl and clobbers VL before we read the correct value.
My assumption was that such a spill would have an explicit VL set somewhere but
that's incorrect - it can just be an unadorned move. And we don't always use
the full-register loads/store that don't need a VL for spilling either: During
lra we have our _lra patterns which do.
This fails with GCC 15 as well BTW.
So it appears we need to model the FoF load as "atomically" setting VL in those
cases. That will make it even more difficult to optimize it but I don't see
any other way. Actually, that's how I started out with the FoF fix but then
opted for a simpler version.
