Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:> Vectorization must know the data layout: whether we have vectors (r1, > i1, r2, i2...) or (r1, r2, ...), (i1, i2, ...). These two approaches > are not compatible. If you have vector registers that can hold 8 > floats, with the first approach you can load 4 complex numbers in a > single instruction, then multiply by another 4 numbers, and store. > With the second approach, the minimum unit of work is 8 numbers, and > each input to the multiplication has to be loaded in two instructions, > loading real and imaginary parts from two separate locations. On most > architectures the second approach would be vastly superior, but the > v4c32 type mentioned in the RFC suggests the first one.That's true. I was assuming that if the vectorizer wants to extract reals from a vector of complex, we'd need an operation to do that that results in a different vector type (say, two v4c32 -> one v8f32). It's a special kind of shufflevector. The reverse operation is also useful.> In addition to that, we shouldn't limit complex types to floating > point only. What we care about is keeping the "ac-bd" together, not > what type a,b,c,d are.Can you give some examples of non-FP types where a higher-level representation would be useful? -David
-----Original Message----- From: David Greene <dag at cray.com> Sent: Wednesday, July 3, 2019 2:44 PM To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> Subject: [EXT] Re: [llvm-dev] RFC: Complex in LLVM Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:>> In addition to that, we shouldn't limit complex types to floating >> point only. What we care about is keeping the "ac-bd" together, not >> what type a,b,c,d are. > > Can you give some examples of non-FP types where a higher-level representation would be useful?Hexagon has instructions to do complex multiplication on pairs i16 x i16 (plus variants like accumulate, conjugate, etc.). Granted, if Hexagon is the only one, this case may not be strong enough to convince everybody, but fixed-point complex arithmetic may actually be useful in practice, especially given the recent addition of fixed-point functionality to clang/llvm. As per your RFC, the issue is with keeping the "intent" clear, which may be lost once complex operations are expanded into the underlying arithmetic (especially if parts of it are simplified). The way I look at it is that if we want to preserve that arithmetic in a single unit, then we should start with that, and leave the input types for later. To be even more explicit, I'd suggest that we should instead have intrinsics for complex operations (and have clang generate them automatically for the standard C complex types), and not bother with defining a complex type in the LLVM IR at all. -Krzysztof
> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -----Original Message----- > From: David Greene <dag at cray.com> > Sent: Wednesday, July 3, 2019 2:44 PM > To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> > Subject: [EXT] Re: [llvm-dev] RFC: Complex in LLVM > > Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> In addition to that, we shouldn't limit complex types to floating >>> point only. What we care about is keeping the "ac-bd" together, not >>> what type a,b,c,d are. >> >> Can you give some examples of non-FP types where a higher-level representation would be useful? > > Hexagon has instructions to do complex multiplication on pairs i16 x i16 (plus variants like accumulate, conjugate, etc.).How difficult are these to pattern match on scalar code? -Chris
Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:>> Can you give some examples of non-FP types where a higher-level representation would be useful? > > Hexagon has instructions to do complex multiplication on pairs i16 x > i16 (plus variants like accumulate, conjugate, etc.).I guess I was asking more about how prevelent these operations are in real codes. I don't see them in HPC codes (at least, not the stuff I've looked at) but other domains are probably very different. And you're right, fixed-point is probably going to become much more important. -David