https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
--- Comment #17 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Vladimir Makarov from comment #16) > (In reply to rsand...@gcc.gnu.org from comment #15) > > (In reply to Jakub Jelinek from comment #14) > > > I think what matters is whether the new asm for those is the same or > > > better > > > than before. If the tests hardcode particular RA decisions, they'll > > > obviously FAIL when something in the RA changes. > > > > The kind of change is from: > > > > mov z2.d, x0 > > movprfx z0, z1 > > uabd z0.d, p0/m, z0.d, z2.d > > ret > > > > to: > > > > mov z0.d, x0 > > mov z2.d, z0.d > > movprfx z0, z1 > > uabd z0.d, p0/m, z0.d, z2.d > > ret > > > > so this is a genuine regression. > > Hi, Richard. Could you write me what options and test (I guess it is > pr91333.c) you used. Sorry for the slow reply. The asm above is from gcc.target/aarch64/sve/acle/asm/abd_u64.c compiled with: ./cc1 -O2 -quiet -DTEST_FULL=1 -isystem include -march=armv8.2-a+sve Arguably we just got lucky with the old allocation. That said, the test case does show up a potential problem, even though it doesn't seem to be relevant to the regression: one of the pseudos has two conflicting hard register preferences, meaning that one of the preferences is bound not to be met. I'm not sure it makes sense to sum the frequencies of each individual preference in that case, since it means that pseudos with conflicting preferences can get a higher priority than registers with a strong single-register preference.
