Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs <a...@codesourcery.com> wrote: >> >> Hi all, >> >> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just >> do it because the GCC middle-end models DIVMOD's return value as >> "complex int" type, and there are no vector equivalents of that type. >> >> Therefore, this patch adds minimal support for "complex vector int" >> modes. I have not attempted to provide any means to use these modes >> from C, so they're really only useful for DIVMOD. The actual libfunc >> implementation will pack the data into wider vector modes manually. >> >> A knock-on effect of this is that I needed to increase the range of >> "mode_unit_size" (several of the vector modes supported by amdgcn exceed >> the previous 255-byte limit). >> >> Since this change would add a large number of new, unused modes to many >> architectures, I have elected to *not* enable them, by default, in >> machmode.def (where the other complex modes are created). The new modes >> are therefore inactive on all architectures but amdgcn, for now. >> >> OK for mainline? (I've not done a full test yet, but I will.) > > I think it makes more sense to map vector CSImode to vector SImode with > the double number of lanes.
Agreed FWIW. This is effectively what AArch64 now does for x2, x3 and x4 tuple types (where x2 is often used for complex values). Thanks, Richard
