On Fri, Aug 13, 2021 at 07:57:53PM -0400, Michael Meissner wrote: > 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.
If we can get rid of ever generating subregs of mem (which has been deprecated for decades now after all -- the last thing stopping removing it was old reload), and we can also do what TARGET_NO_SF_SUBREG does some other way, we could allow register_operand in the port again. As it is, we need to avoid it as a pattern predicate. > 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. Not an unreasonable thing to do. But for that same reason, thinking it is good because surrounding code does the same thing, is a trap as well! Segher
