search for: ymm6

...rms. This thread has lots of interesting information: http://software.intel.com/en-us/forums/showthread.php?t=59291 I wasn't able to find a formal Win64 ABI spec, but according to http://www.agner.org/optimize/calling_conventions.pdf, xmm6-xmm15 are callee-saved on win64, but the high bits in ymm6-ymm15 are not. That's not currently correctly modelled in LLVM. To fix it, create a pseudo-register YMMHI_CLOBBER that aliases ymm6-ymm15. Then add YMMHI_CLOBBER to the registers clobbered by WINCALL64*. /jakob

...# @test # BB#0: # %entry pushq %rbp movq %rsp, %rbp subq $64, %rsp vmovaps %xmm7, -32(%rbp) # 16-byte Spill vmovaps %xmm6, -16(%rbp) # 16-byte Spill vmovaps %ymm3, %ymm6 vmovaps %ymm2, %ymm7 vaddps %ymm7, %ymm0, %ymm0 vaddps %ymm6, %ymm1, %ymm1 callq foo vsubps %ymm7, %ymm0, %ymm0 vsubps %ymm6, %ymm1, %ymm1 vmovaps -16(%rbp), %xmm6 # 16-byte Reload vmovaps -32(%rbp), %xmm7 # 16-byte...

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 works. It saves the registers holding values, it doesn't care which alias is clobbered. Are you

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. 2. The callee preserves XMMs but works with YMMs and clobbering them. 3. So after the call, the upper part of YMM is gone. - Elena -----Original Message----- From: Bruno Cardoso Lopes [mailto:bruno.cardoso at

...size: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 > $name:ymm7;bitsize:256;offset:499;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:24;dwarf:24;#00 > $qRegisterInfo63#ab > $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

...nc_float16_ptr(<16 x float> %x, <16 x float>* %y) >> %2 = load <16 x float>* %y, align 16 >> %3 = fadd <16 x float> %2, %1 >> ret <16 x float> %3 >> @@ -43,21 +43,21 @@ define <16 x float> @testf16_inp(<16 x f >> ; preserved ymm6-ymm15 >> ; WIN64: testf16_regs >> ; WIN64: call >> -; WIN64: vaddps {{%ymm[6-7]}}, %ymm0, %ymm0 >> -; WIN64: vaddps {{%ymm[6-7]}}, %ymm1, %ymm1 >> +; WIN64: vaddps {{%ymm[6-7]}}, {{%ymm[0-1]}}, {{%ymm[0-1]}} >> +; WIN64: vaddps {{%ymm[6-7]}}, {{%ymm[0-1]}}, {...