On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote: > There is a song from Sesame Street: "Which of these is not like the > others?" altivec.md seems like an outlier. crypto.md and vsx.md also > seem unusual. > > We have > > register_operand > gpc_reg_operand > altivec_register_operand > vsx_register_operand > > among various relevant options. It seems like this deserves to be > cleaned up sometime, but a patch for xxeval is not the time.
As the person who added altivec_register_operand, vsx_register_opernd, and various others, the original reason for adding these were to eliminate some issues we were seeing with register allocation, where the pre-LRA register allocator would often do wonky things, and not allowing GPRs helped eliminate some of the reloads. There were some passes, particularly after register allocation that didn't look at the constraints. Now that we've had LRA for awhile, maybe it is time to rethink these. However, before somebody goes whole hog changing things, there are some specific places where these are needed (mostly in the define_splits and the split portion of define_insn_and_split because constraints aren't allowed). I did actually think whether to use gpc_reg_operand or vsx_register_operand. I opted to use register_operand just because most of the surrounding code used it. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
