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. In fact since divmod is a libgcc function I wonder where your vector variant would reside and how GCC decides to emit calls to it? That is, there's no way to OMP simd declare this function? Richard. > Thanks > > Andrew
