search for: ymm5

...x64 calling convention while adding support for HVA and vector types. There are four main differences: - Floating-point types are considered vector types just like __m128, __m256 and __m512. The first 6 vector typed arguments are saved in physical registers XMM0/YMM0/ZMM0 until XMM5/YMM5/ZMM5. - After vector types and integer types are allocated, HVA types are allocated, in ascending order, to unused vector registers XMM0/YMM0/ZMM0 to XMM5/YMM5/ZMM5. - Just like in the default x65 CC, Shadow space is allocated for vector/HVA types. The size is fixed to 8 byte...

On Jan 9, 2012, at 10:00 AM, Jakob Stoklund Olesen wrote: > > On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > >> I'll explain what we see in the code. >> 1. The caller saves XMM registers across the call if needed (according to DEFS definition). >> YMMs are not in the set, so caller does not take care. > > This is not how the register allocator

...ithSubRegs<"ymm2", [XMM2, XMM2b]>, DwarfRegNum<[19, 23, 23]>; def YMM3: RegisterWithSubRegs<"ymm3", [XMM3, XMM3b]>, DwarfRegNum<[20, 24, 24]>; def YMM4: RegisterWithSubRegs<"ymm4", [XMM4, XMM4b]>, DwarfRegNum<[21, 25, 25]>; def YMM5: RegisterWithSubRegs<"ymm5", [XMM5, XMM5b]>, DwarfRegNum<[22, 26, 26]>; def YMM6: RegisterWithSubRegs<"ymm6", [XMM6, XMM6b]>, DwarfRegNum<[23, 27, 27]>; def YMM7: RegisterWithSubRegs<"ymm7", [XMM7, XMM7b]>, DwarfRegNum<[24, 28, 28]&...

Dave Yeo wrote: > Seems that the default binutils on OS/2 is too old to support AVX2, > attached patch works around this. Not the best solution as best would be > configure tests, but simple. Are you sure that these binutils support AVX and FMA? (Currently libFLAC doesn't contain AVX and FMA instructions). If they aren't supported then it's better to include them too into

...libFLAC' CC lpc_intrin_avx2.lo R:/tmp/ccwvrScM.s: Assembler messages: R:/tmp/ccwvrScM.s:495: Error: operand type mismatch for `vbroadcastss' ... R:/tmp/ccwvrScM.s:8773: Error: operand type mismatch for `vpsrlq' R:/tmp/ccwvrScM.s:8778: Error: no such instruction: `vpermd %ymm1,%ymm5,%ymm0' R:/tmp/ccwvrScM.s:8859: Error: operand type mismatch for `vpmovzxdq' ... Best to be safe so updated patch attached. I've also opened a ticket, http://trac.netlabs.org/rpm/ticket/165#ticket Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: 0...

...t;); + printf("%-40s", "Testing vmovsd %xmm5,(%ecx)..."); + memset(res, 0x88, 64); + memset(res + 10, 0x77, 8); + if ( stack_exec && cpu_has_avx ) + { + extern const unsigned char vmovsd_to_mem[]; + + asm volatile ( "vbroadcastsd %0, %%ymm5\n" + ".pushsection .test, \"a\", @progbits\n" + "vmovsd_to_mem: vmovsd %%xmm5, (%1)\n" + ".popsection" :: "m" (res[10]), "c" (NULL) ); + + memcpy(instr, vmovsd_t...

...size:256;offset:371;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:20;dwarf:20;#00 > $qRegisterInfo5f#dd > $name:ymm4;bitsize:256;offset:403;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:21;dwarf:21;#00 > $qRegisterInfo60#a8 > $name:ymm5;bitsize:256;offset:435;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:22;dwarf:22;#00 > $qRegisterInfo61#a9 > $name:ymm6;bitsize:256;offset:467;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:23;dwarf:23;#00 > $qRegisterInfo62#aa > $n...

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude