> 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.Hal, we had 128-bit complex in an earlier draft of David's proposal, but thought it to be an unnecessary distraction from our main interest, which is complex composed of 32-bit and 64-bit FP. I'll take responsibility for having prodded him to remove it. :) We're most interested in seeing complex supported in LLVM to help with compiling complex types in C and C++, where there is general understanding of complex when it's commonly composed of a pair of floats or doubles. Once you get beyond 32-bit and 64-bit FP as the constituent type though, you're in "complex long double" territory, and that introduces confusion. Many expect complex long double to have 128-bit parts, but long double can mean 80-bit FP. Although we personally haven't seen much practical use of a complex type composed of 80-bit FP, we thought that proposing complex for 128-bit FP might require also covering the 80-bit FP case. What long double means is, after all, a Clang issue and not an LLVM issue, but we figured that proposing more types would have a harder path to success than proposing fewer types. Do you think it's best to have the full set (c32, c64, c80, c128) or just (c32, c64, c128)? -Troy
If I understand the proposal correctly these new types aren't really limited to floating point. We probably want to use them for fixed point types as well c32 %res = smul.fix c32 %a, c32 %b, i16 31 v4c32 %res = sadd.sat v4c32 %a, v4c32 %b at least if that simplifies loop vectorization etc. Then it would be neat to also have c16. (btw, downstream we'd probably try to add c24 and c40 as well, similar to what we do today for i24 and i40 types). Regards, Björn> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Troy > Johnson via llvm-dev > Sent: den 2 juli 2019 05:29 > To: Finkel, Hal J. <hfinkel at anl.gov>; David Greene <dag at cray.com> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] RFC: Complex in LLVM > > > 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. > > Hal, we had 128-bit complex in an earlier draft of David's proposal, but > thought it to be an unnecessary distraction from our main interest, which > is complex composed of 32-bit and 64-bit FP. I'll take responsibility > for having prodded him to remove it. :) > > We're most interested in seeing complex supported in LLVM to help with > compiling complex types in C and C++, where there is general > understanding of complex when it's commonly composed of a pair of floats > or doubles. Once you get beyond 32-bit and 64-bit FP as the constituent > type though, you're in "complex long double" territory, and that > introduces confusion. Many expect complex long double to have 128-bit > parts, but long double can mean 80-bit FP. Although we personally > haven't seen much practical use of a complex type composed of 80-bit FP, > we thought that proposing complex for 128-bit FP might require also > covering the 80-bit FP case. What long double means is, after all, a > Clang issue and not an LLVM issue, but we figured that proposing more > types would have a harder path to success than proposing fewer types. > > Do you think it's best to have the full set (c32, c64, c80, c128) or just > (c32, c64, c128)? > > -Troy > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Björn Pettersson A <bjorn.a.pettersson at ericsson.com> writes:> If I understand the proposal correctly these new types aren't really > limited to floating point.Currently they are but we could relax that.> We probably want to use them for fixed point types as well > > c32 %res = smul.fix c32 %a, c32 %b, i16 31 > v4c32 %res = sadd.sat v4c32 %a, v4c32 %bWouldn't we want a different type for such a thing? I'm trying to come up with a good name fox complex<fixed-point>. Originally I thought maybe ci32 but that might be interpreted as a Gaussian integer. Is a Gaussian integer type useful? I haven't ever seen it used in my time here (though I can't claim to have super-deep knowledge of full applications) but maybe it's more prominent in other domains.> at least if that simplifies loop vectorization etc.It probably would.> Then it would be neat to also have c16.Agreed.> (btw, downstream we'd probably try to add c24 and c40 as well, > similar to what we do today for i24 and i40 types).As I said in my reply to Hal, a general complex<floating-or-fixed-type> may be the way to go. -David