[llvm-dev] RFC: Complex in LLVM

[Björn Pettersson A via llvm-dev]

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