[llvm-dev] Complex proposal v3 + roundtable agenda

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 24 14:55:38 PST 2020


Sorry, got sidetracked.

My concern here was really that we didn't lose sight of SoA-based implementations of complex arithmetic. I agree that having intrinsics for both layouts would likely make most targets happy.

--
Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development

-----Original Message-----
From: Florian Hahn <florian_hahn at apple.com>
Sent: Tuesday, November 24, 2020 3:16 PM
To: cameron.mcinally at nyu.edu; llvm-dev <llvm-dev at lists.llvm.org>; Krzysztof Parzyszek <kparzysz at quicinc.com>
Subject: [EXT] Re: [llvm-dev] Complex proposal v3 + roundtable agenda



> On Nov 19, 2020, at 18:11, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> 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.


I think that’s a key point. I think the set of instructions for complex math out there are probably much more varied than other parts of vector extensions.

This is another area that would benefit from making progress early and iterating on the details with people interested in different targets IMO. For example, we could have intrinsics for both layouts and decide which one to pick depending on the target. Converting between layouts should be easily doable in IR as well, although at some cost.

Cheers,
Florian


More information about the llvm-dev mailing list