On Thu, Aug 19, 2021 at 06:10:46PM -0400, Michael Meissner wrote: > On Wed, Aug 18, 2021 at 06:11:03PM -0500, Segher Boessenkool wrote: > > I think the current vector.md / altivec.md / vsx.md / rs6000.md > > division is artificial at best. Most of the basic (movement etc.) > > things are in rs6000.md (and all should be), but nothing else is clear. > > > > The name "altivec.md" suggests it is only for the very old things, but > > it is not used that way, and that it untenable anyway: we have more > > recent insns to plug holes in that (for example 64-bit integer support), > > so it arguably is not just for that. > > > > Using it for instructions that only work on the high 32 VSRs (i.e. the > > VRs) is quite artificial as well -- sometimes there are equivalent insns > > for the other 32 VSRs already, sometimes it is just because of opcode > > scarcity, sometimes it is because it is for the slow vector unit only > > (but those seem to live in rs6000.md and crypto.md anyway). > > > > Maybe we should give up on dividing these things, and put both in one > > file, say vector.md? > > Yes but that is more ambitious.
Absolutely. But setting a destination before starting to walk is sometimes helpful ;-) > Basically I have 2 patches coming that use and > update the xxsplti instructions. I can avoid putting in this specific change > and reformulate them for altivec.md instead of vsx.md. Or I can check in > these > changes. Which do you want? I don't want to do both insn movement and new > patches at the same time. I am fine with this patch, it is a clear improvement already. > The original design of vector.md was to allow for alternate vector units, and > vector.md was just the define_expands. But the likely hood of new vector > units > is probably low. Right, history has caught up with us. > When I wrote vsx.md in the power7 days, we were toying with the notion of > doing > VSX and not Altivec instructions. But I quickly realized you always need > Altivec for VSX. There also were 8-byte vectors back then. Or was that completely separate code? > In general, I would prefer not to have a flag day where everything gets moved > all at once. Yup, it is too easy to make mistakes here, ordering in machine descriptions is significant. Although comparing the generated insn-* files before and after might help. Segher
