https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> --- (In reply to Nicholas Krause from comment #9) > Sorry if I'm misunderstanding the power code but is there a way to rewrite > the test to: > if (VECTOR_MEM_ALTIVEC(mode) > and another branch for VSX_P instructions. There's no need. > I'm assuming that because its checking both we can get a infinite loop. I'm > assuming that in order to hand this off to the LRA we will need to > rewrite in to have two paths one for VSX_P and one for standard MEM_ALTIVEC. No. We get into an infinite loop, because LRA passes us a valid Altivec type address and rs6000_legitimate_address_p erroneously tells LRA, that it is invalid. So LRA tries to spill it again. After a few iterations of that, the address is simplified to just a register inside the (and: ...) and that is trivially valid, but rs6000_legitimate_address_p continues to say it's invalid. At this point, LRA replaces that one reg with a copy of the one reg. Again, rs6000_legitimate_address_p says it's invalid, so around and around it goes. The bug isn't that we cannot recognize the address as valid. It's that we have a bogus test that uses VECTOR_MEM_ALTIVEC_P(), which only is true for vector modes, when Altivec is enabled and VSX is disabled. When VSX is enabled (which implies Altivec is enabled), VECTOR_MEM_ALTIVEC_P() return false. That is because rs6000_vector_mem[<vector mode>] returns VECTOR_VSX rather than VECTOR_ALTIVEC when VSX is enabled.
