[llvm-dev] RFC: Complex in LLVM

[Finkel, Hal J. via llvm-dev]

On 7/2/19 10:45 AM, David Greene wrote:
> "Finkel, Hal J." <hfinkel at anl.gov> writes:
>
>> I think that it's really important that we're specific about the goals
>> here. Exactly what kinds of optimizations are we aiming to (more-easily)
>> enable? There certainly exists hardware with instructions that help
>> vectorize complex multiplication, for example, and having a builtin
>> complex type would make writing patterns for those instructions easier
>> (as opposed to trying to build matching into the SLP vectorizer or
>> elsewhere). This probably makes constant-folding calls to complex libm
>> functions easier.
> Yes, all of that.  Plus things like instcombine, expression
> rewrites/simplification and so on.
>
>> Does this make loop vectorization easier or harder? Do you expect the
>> vectorizer to form vectors of these complex types?
> I expect the vectorizer to form vectors of complex types, yes.  I
> suspect having a first-class complex type will make vectorization
> easier.
>
>>> We defer a c128 type (like std::complex<long double>) for a future
>>> RFC.
>>
>> Why? I'd prefer we avoid introducing even more special cases. Is there
>> any reason why we should not define "complex <scalar type>", or to be
>> more restrictive, "complex <floating-point type>"? I really don't like
>> the idea of excluding 128-bit complex types, and I think that we can
>> have a generic facility.
> Troy already addressed this but I'm very happy to re-add c128.  I think
> complex <floating-point-type> would be fine.


Great.


>   Of course some
> floating-point-types only make sense on certain targets.  How would we
> legalize a c24 on a target that doesn't support it natively?  Calls into
> compiler-rt?


I think that we can have a sensible system for all current types: For 
the various types, we have:

   - x86_fp80 (and perhaps x86_mmx): Lowering for these is only 
supported in relevant x86 configurations, and lowering the complex 
variants will likewise work only in any relevant target configurations .

   - float, double: Lowering for these has an ABI, and we can use that 
ABI (runtime calls, expansions).

   - fp128 and ppc_fp128: On systems which support these, they're used 
for _Complex long double, and so there is an ABI to follow.

   - half: half may have an ABI on some systems, in which case we can 
follow it, and on other systems it is treated as a "storage only" type, 
which operations being promoted to single precision, and we can do the 
same for the default lowering.

  -Hal


>
> We had quite a bit of discussion around naming here.  If we're expanding
> this to allow general floating point types, is c<bit-width> still a good
> name?
>
>                          -David

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory