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.
Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> writes:> 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.Great ideas. Are there downsides to making complex a subclass of an aggregate? I am thinking mainly WRT vectorization. Does the vectorizer expect elements to be scalar/non-aggregate types? -David
On 7/3/19 2:01 PM, David Greene wrote:> Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> 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. > Great ideas. Are there downsides to making complex a subclass of an > aggregate? I am thinking mainly WRT vectorization. Does the vectorizer > expect elements to be scalar/non-aggregate types?I expect that there are minor changes that would be needed in a bunch of different places, but I suspect no worse than adding a novel type. For example, VectorType::isValidElementType needs to be updated regardless. -Hal> > -David-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory