[llvm-dev] RFC: Complex in LLVM

[Tian, Xinmin via llvm-dev]

>>>I expect the vectorizer to form vectors of complex types, yes.  I suspect having a first-class complex type will make vectorization easier.

Yes, in ICC, complex is the first class data type, it makes vectorization easier. It enables code generator to avoid "gathers ... " with "load-shuffle ..." sequence for a better performance.  

I agree with Hal, I would suggest to add c128 as well, as LLVM is being used for developing Fortran compiler as well. 

Thanks, 
Xinmin 

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Greene via llvm-dev
Sent: Tuesday, July 2, 2019 8:46 AM
To: Finkel, Hal J. <hfinkel at anl.gov>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] RFC: Complex in LLVM

"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
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev