search for: v4c32

...reuse of floating point constants. Operations ---------- This proposal overloads existing floating point instructions for complex types in order to leverage existing expression optimizations: c64 %res = fadd c64 %a, c64 %b v8c64 %res = fsub v8c64 %a, v8c64 %b c128 %res = fmul c128 %a, c128 %b v4c32 %res = fdiv v4c64 %a, v4c64 %b The only valid comparisons of complex values shall be equality: i1 %res = eq c32 %a, c32 %b i8 %res = eq v8c32 %a, v8c32 %b i1 %res = ne c64 %a, c64 %b i8 %res = ne v8c64 %a, v8c64 %b select is defined for complex: c32 = select i1 %cmp, c32 %a, c32 %b v4c64 = sel...

...vdef c16 : ValueType<32, uuu> def c32 : ValueType<64, vvv> def c64 : ValueType<128, www> def x86c80 : ValueType<160, xxx> def c128 : ValueType<256, yyy> def ppcc128 : ValueType<256, zzz> def v8c16 : ValueType<128, aaa> def v4c32 : ValueType<128, bbb> def v4c64 : ValueType<512, ccc> ... def nxv8c16 : ValueType<128, ddd> def nxv4c32 : ValueType<128, eee> def nxv1c64 : ValueType<128, fff> def nxv2c64 : ValueType<256, ggg> ... def llvm_anycomplex_ty : LLVMType<Any>; d...

...; > def c32 : ValueType<64, vvv> > def c64 : ValueType<128, www> > def x86c80 : ValueType<160, xxx> > def c128 : ValueType<256, yyy> > def ppcc128 : ValueType<256, zzz> > > def v8c16 : ValueType<128, aaa> > def v4c32 : ValueType<128, bbb> > def v4c64 : ValueType<512, ccc> > ... > > def nxv8c16 : ValueType<128, ddd> > def nxv4c32 : ValueType<128, eee> > def nxv1c64 : ValueType<128, fff> > def nxv2c64 : ValueType<256, ggg> > ... >...

> 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

...; >> [...] >> >> llvm.extractreal.* - Overloaded intrinsic to create a vector of >> floating-point type from the real portions of a >> vector of complex (not all variants shown) >> >> declare v4f32 @llvm.extractreal.v4c32(v4c32 %val) declare v4f64 >> @llvm.extractreal.v4c64(v4c64 %val) >> >> llvm.extractimag.* - Overloaded intrinsic to create a vector of >> floating-point type from the imaginary portions >> of a vector of complex (not all varian...

...With the second approach, the minimum unit of work is 8 numbers, and > each input to the multiplication has to be loaded in two instructions, > loading real and imaginary parts from two separate locations. On most > architectures the second approach would be vastly superior, but the > v4c32 type mentioned in the RFC suggests the first one. That's true. I was assuming that if the vectorizer wants to extract reals from a vector of complex, we'd need an operation to do that that results in a different vector type (say, two v4c32 -> one v8f32). It's a special kind of shu...

...ar types or we may want to put them somewhere else. Operations This proposal overloads existing floating point instructions for complex types in order to leverage existing expression optimizations: c64 %res = fadd c64 %a, c64 %b v8c64 %res = fsub v8c64 %a, v8c64 %b c32 %res = fmul c64 %a, c64 %b v4c32 %res = fdiv v4c64 %a, v4c64 %b The only valid comparisons of complex values will be equality: i1 %res = eq c32 %a, c32 %b i8 %res = eq v8c32 %a, v8c32 %b i1 %res = ne c64 %a, c64 %b i8 %res = ne v8c64 %a, v8c64 %b select is defined for complex: c32 = select i1 %cmp, c32 %a, c32 %b v4c64 = sele...