llvm dev - Nov 2020 - Complex proposal v3 + roundtable agenda

> On Nov 13, 2020, at 15:11, Krzysztof Parzyszek via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Examples of complex instructions?  Hexagon has a cmpy instruction for
complex multiplication, although it works on int16-based values.  There is a
whole set of these instructions (with various saturation/rounding behaviors),
but each one of them can multiply two complex numbers (where a complex number is
represented as two 16-bit values in a 32-bit register). That's a fairly
complex pattern to match, and it could be quite easily disturbed by various
arithmetic simplifications.
> 
> What I meant with the second part was that if we start with intrinsics,
then on targets that don't support complex arithmetic, those intrinsics
could be expanded into the explicit real-number-based arithmetic in instcombine.
This could be communicated via a function in TargetTransformInfo.  Instcombine
already allows targets to handle their own intrinsics in it, so maybe this would
still fall under that category.  This could improve performance in the short
term, while the knowledge of the intrinsics is gradually added to the rest of
the code.

That’s a good point! I think one challenge will be that the hardware
instructions might be quite different from target to target. I was thinking that
we could just introduce/use those intrinsics on targets where the can be lowered
efficiently.

Once we have support in the vectorizers, it might be beneficial to use the
intrinsics even for targets that do not natively support them. I think for that
cases, adding a pass that lowers them to regular IR instructions for targets
that do not have dedicated instructions would be a great idea. I think we did
something similar for the experimental reduction intrinsics.

Cheers,
Florian

Florian Hahn <florian_hahn at apple.com> writes:
> Once we have support in the vectorizers, it might be beneficial to use
> the intrinsics even for targets that do not natively support them. I
> think for that cases, adding a pass that lowers them to regular IR
> instructions for targets that do not have dedicated instructions would
> be a great idea. I think we did something similar for the experimental
> reduction intrinsics.
We don't *need* intrinsics to do such lowering.  "Normal" LLVM
instructions with a first-class complex type is similarly lowerable.

I'm not necessarily opposed to intrinsics (especially if we have Simon's
generic matchers available) but I think it's important to be clear what
we're talking about.  Intrtinaics vs. first-class complex types have
different tradeoffs.  With Simon's generic matchers those trade-offs are
less stark to me though.

                  -David

> On 18 Nov 2020, at 21:15, David Greene <dag at cray.com> wrote:
> 
> Florian Hahn <florian_hahn at apple.com> writes:
> 
>> Once we have support in the vectorizers, it might be beneficial to use
>> the intrinsics even for targets that do not natively support them. I
>> think for that cases, adding a pass that lowers them to regular IR
>> instructions for targets that do not have dedicated instructions would
>> be a great idea. I think we did something similar for the experimental
>> reduction intrinsics.
> 
> We don't *need* intrinsics to do such lowering.  "Normal"
LLVM
> instructions with a first-class complex type is similarly lowerable.
> 
Yes, I did not mean to imply that. The snippet above was not intended to compare
intrinsics/first-class type versions. It was only meant to state that a generic
lowering pass would be useful, so we can use the intrinsics even for targets
that cannot lower them natively.
> I'm not necessarily opposed to intrinsics (especially if we have
Simon's
> generic matchers available) but I think it's important to be clear what
> we're talking about.  Intrtinaics vs. first-class complex types have
> different tradeoffs.  With Simon's generic matchers those trade-offs
are
> less stark to me though.

Agreed. I think various places in the thread explore some trade-offs in detail.

Cheers,
Florian