Alan Modra wrote: > The reason this fails is that no alternative in altivec_mov<mode> > exactly matches. Ideally reload would choose the Z,v alternative > (cost 9) and you'd get an address reload for the mem to make it match > the "Z" constraint. Instead reload chooses the Y,r alternative (cost > 8) as best. > > That's a bad choice. "Y" matches the r3+16 mem so no reloads needed > for the mem, however the altivec reg needs to be reloaded to gprs. > Without direct moves from altivec to gpr the reload needs to go via > mem, so you get an altivec store to stack plus gpr load from stack. > The store to stack has the same form as the original store. Oops, no > progress. > > Even if direct moves were available from altivec regs to gprs, the Y,r > alternative would still be a bad choice. > > I believe all the r alternatives in altivec_mov<mode> should be > disparaged with "?".
I agree that this makes sense just from a code quality perspective. However, there still seems to be another underlying problem: reload should never generate invalid instructions. (Playing with '?' to fix *inefficient* instructions is fine, but we shouldn't rely on '?' to fix *invalid* instructions.) If reload -for whatever reason- wants to emit a vr->gpr move, then it should generate a valid instruction sequence to do so, via secondary reloads if necessary. I think it would be a good idea to investigate why that isn't happening in this test case. [ There is a chance that the underlying bug will reappear in a different context, even after the '?' change is applied. ] Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
