On Thu, Aug 03, 2017 at 10:01:41AM -0500, Segher Boessenkool wrote: > Hi Mike, > > On Wed, Aug 02, 2017 at 10:28:55AM -0400, Michael Meissner wrote: > > On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote: > > > I think calling this with the rtx elementN args makes this only more > > > complicated (the function comment doesn't say what they are or what > > > NULL means, btw). > > You didn't handle the first part of this as far as I see? It's the > big complicating issue here.
I am not sure exactly what you are asking for. This is like the other output functions that take the rtx insns. > > + If ELEMENT1 is null, use the top 64-bit double word of ARG1. If it is > > + non-NULL, it is a 0 or 1 constant that gives the vector element number > > to > > + use for extracting the 64-bit double word from ARG1. > > + > > + If ELEMENT2 is null, use the top 64-bit double word of ARG2. If it is > > + non-NULL, it is a 0 or 1 constant that gives the vector element number > > to > > + use for extracting the 64-bit double word from ARG2. > > + > > + The element number is based on the user element ordering, set by the > > + endianess and by the -maltivec={le,be} options. */ > > ("endianness", two n's). > > I don't like using NULL as a magic value at all; it does not simplify > this interface, it complicates it instead. > > Can you move the "which half is high" decision to the callers? And then essentially there is no need for the function, since each of the 4 concat variants have to have the logic to support big endian, -maltivec=be, and -maltivec=le. Let me see what I can do about it. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797