"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
>>>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
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
"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes:>> 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.Sounds reasonable. -David