[llvm-dev] RFC: Complex in LLVM

[David Greene via llvm-dev]

"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.  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?

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