https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123108
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> --- The pattern has no constraints defined. THat's uncommon outside the RISC-V port and is a path that is likely not well exercised. Essentially in that scenario curr_insn_transform won't do anything. I *suspect* part of what's going on here we had some ancient code in reload that allowed substitution of an equivalence for a pseudo *without* immediate recognition or constraint checking. We then relied on later steps in reload to fix up the turds left by that code. I have a sneaking suspicion that braindamaged code ultimately ended up in LRA (see loc_equivalence_change_p). So we slam in the (const_int 32) equivalence. Then eventually call curr_insn_transform which does nothing and that bogus (const_int 32) hangs around and causes various problems depending on exactly when we re-recognize or split and recognize the result, or do vsetvl insertion. A workaround is to ensure the pattern has suitable constraints. It looks like many patterns are potentially subject to this problem. There may be other fixes that would require more chasing through LRA. But right now, that's what I see.
