https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559
--- Comment #3 from Robin Dapp <rdapp at gcc dot gnu.org> --- I got back to this again today, now that pressure-aware scheduling is the default. As mentioned before, it helps but doesn't get rid of the spills. Testing with the "generic ooo" scheduling model it looks like vector load/store latency of 6 is too high. Yet, even setting them to 1 is not enough to get rid of spills entirely. What helps is additionally lowering the vector alu latency to 2 (from the default 3). I'm not really sure how to properly handle this. As far as I can tell spilling is always going to happen if we try to "wait" for dependencies and delay the dependent instructions. In my experience the hardware does a better job at live scheduling anyway and we only make things worse in several cases. Previously I experimented with setting the latency of most instructions to 1 with few exceptions and instead ensure a proper instruction mix i.e. trying to keep every execution unit busy. That's not a panacea either, though.
