On Wed, Aug 18, 2021 at 06:11:03PM -0500, Segher Boessenkool wrote: > On Wed, Aug 18, 2021 at 04:42:42PM -0400, David Edelsohn wrote: > > I wanted to give Segher a chance to comment on the structure. > > 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. 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. 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. 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. In general, I would prefer not to have a flag day where everything gets moved all at once. -- 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
