[llvm-dev] RFC: Complex in LLVM

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 2 11:11:03 PDT 2019


On 7/2/19 10:57 AM, David Greene via llvm-dev wrote:
> Tim Northover <t.p.northover at gmail.com> writes:
>
>> On Mon, 1 Jul 2019 at 19:56, David Greene via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> llvm.creal.* - Overloaded intrinsic to extract the real part of a
>>>                 complex value
>>> declare float  @llvm.creal.c32(c32 %Val)
>>> declare double @llvm.creal.c64(c64 %Val)
>> What are your plans for the reverse? I assume we don't want the only
>> way to materialize a complex to be via memory so an insertvalue
>> equivalent (or maybe using insertvalue/extractvalue directly?) and a
>> literal value would probably be useful.
> Good points.  Originally I put the creal/cimag intrinsics in the
> proposal when the layout of the complex type was left unspecified.
> After internal feedback, I changed it to an explicitly-specified layout
> (real followed by imaginary).  Maybe creal/cimag should go away.  Then
> we wouldn't have to teach the optimizer about them and it already
> understands insertvalue/extractvalue.  Of course it might have to be
> taught about insertvalue/extractvalue on a complex type anyway.  So I
> dunno, is there a strong preference one way or the other?


One option is to make the complex type a special kind of vector, or a 
special kind of aggregate (I have a slight preference for the latter). 
That gives us an existing set of accessors.

  -Hal


>
>                              -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list