[llvm-dev] Complex proposal v3 + roundtable agenda
Florian Hahn via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 24 13:16:24 PST 2020
> 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