David Greene via llvm-dev
2020-Nov-18 21:12 UTC
[llvm-dev] Complex proposal v3 + roundtable agenda
Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:> Examples of complex instructions?Sorry, I was referring specifically to this statement:>> Without intrinsics it may be hard to use such instructions especially >> because of the arithmetic simplifications.I was asking the question in the context of intrinsics vs. a first-class complex type. Matching things like hardware support for complex multiply is doable with either mechanism. Your statement made it sound like intrinsics were needed to *avoid* simplifcations in order to match them to hardware instructions and that a first-class complex type (using "normal" LLVM arithmetic instructions) would not be matchable to some hardware instructions. I was curious about what those cases would be. -David
Krzysztof Parzyszek via llvm-dev
2020-Nov-18 21:47 UTC
[llvm-dev] Complex proposal v3 + roundtable agenda
I missed the proposal for a first-class complex type, so I was thinking about working directly on pairs of numbers. I still think that intrinsics are better than a complex type. Intrinsics can be type-agnostic (i.e. overloaded), which would allow them to operate on complex number with any underlying type. Most applications want floating-point values, but on Hexagon we may want to use int16. Complex type would pose another issue for vectorization: in general it's better to have a vector of the real parts and a vector of the imaginary parts for the purpose of arithmetic, than having vectors of complex elements (i.e. real and imaginary parts interleaved). -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development -----Original Message----- From: David Greene <greened at obbligato.org> Sent: Wednesday, November 18, 2020 3:13 PM To: Krzysztof Parzyszek <kparzysz at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Complex proposal v3 + roundtable agenda Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:> Examples of complex instructions?Sorry, I was referring specifically to this statement:>> Without intrinsics it may be hard to use such instructions especially >> because of the arithmetic simplifications.I was asking the question in the context of intrinsics vs. a first-class complex type. Matching things like hardware support for complex multiply is doable with either mechanism. Your statement made it sound like intrinsics were needed to *avoid* simplifcations in order to match them to hardware instructions and that a first-class complex type (using "normal" LLVM arithmetic instructions) would not be matchable to some hardware instructions. I was curious about what those cases would be. -David
Cameron McInally via llvm-dev
2020-Nov-19 18:11 UTC
[llvm-dev] Complex proposal v3 + roundtable agenda
On Wed, Nov 18, 2020 at 4:47 PM Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Complex type would pose another issue for vectorization: in general it's better to have a vector of the real parts and a vector of the imaginary parts for the purpose of arithmetic, than having vectors of complex elements (i.e. real and imaginary parts interleaved).Is that universally true? I think it depends on the target. Let's take Florian's FCMLA example. The inputs and output are interleaved. And if you need just the reals/imags from an interleaved vector for something else, LD2/ST2 should be pretty fast on recent chips. On the other hand, if we had a non-interleaved complex representation and wanted to use FCMLA, we'd need some number of zips and unzips to interleave and deinterleave between the load and store. Those probably aren't cheap in aggregate. I haven't studied this across all targets, but my intuition says we should leave the representation decision up to the targets. Maybe we should have a larger discussion about it. Although, it's worth noting that predication would likely be *much* easier with a non-interleaved representation. I think. Again, I haven't thought this completely through, but it's probably worth talking about.