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? -David
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
On Tue, 2 Jul 2019 at 19:11, Finkel, Hal J. <hfinkel at anl.gov> wrote:> 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.I agree non-vector. If nothing else a vector of complexes seems like a sensible concept which would be harder if a complex was itself vectorial. Myself, I think I do favour insertvalue/extractvalue over intrinsics (which is probably a +1 for isAggregate too by extension). If the notation for the literal is especially re/im rather than 0/1 we might think about adding "extractvalue %v, real" as sugar (that last arg is already weird). All just things to think about right now though. Cheers. Tim.