search for: xmm11

...GFLOP/s 3 threads 2.209838 GFLOP/s 4 threads 2.940443 GFLOP/s When I rewrite the generated assembly by hand to exhibit the same interleaving as in the LLVM IR form . . mulss %xmm8, %xmm10 mulss %xmm7, %xmm9 mulss %xmm6, %xmm3 mulss %xmm5, %xmm11 mulss %xmm8, %xmm10 mulss %xmm7, %xmm9 mulss %xmm6, %xmm3 mulss %xmm5, %xmm11 mulss %xmm8, %xmm10 mulss %xmm7, %xmm9 . . observed performance increases by nearly a factor of four: 1 threads 2.067118 GFLOP/s 2 threads 5.56...

...6InstrControl.td. The call instructions are all prefixed > by: > > let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, > FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, > XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, > XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], > > This is the fixed list of call-clobbered registers. It should really > be controlled by the calling convention of the called function > instead. > > The WINCALL* instructions only exist because of this. Ahh I see now. I hacked this up an...

...all instructions are all prefixed >> by: >> >> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >> XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, >> XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], >> >> This is the fixed list of call-clobbered registers. It should really >> be controlled by the calling convention of the called function >> instead. >> >> The WINCALL* instructions only exist because of this. > Ahh I...

...l prefixed >>> by: >>> >>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >>> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >>> XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, >>> XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], >>> >>> This is the fixed list of call-clobbered registers. It should really >>> be controlled by the calling convention of the called function >>> instead. >>> >>> The WINCALL* instructions only exist becau...

...nstructions are all prefixed by: let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], This is the fixed list of call-clobbered registers. It should really be controlled by the calling convention of the called function instead. The WINCALL* instructions only exist because of this. One problem is that calling conventions are handled while build...

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

...%XMM0<imp-def,dead>, %XMM1<imp-def,dead>, %XMM2<imp-def,dead>, %XMM3<imp-def,dead>, %XMM4<imp-def,dead>, %XMM5<imp-def,dead>, %XMM6<imp-def,dead>, %XMM7<imp-def,dead>, %XMM8<imp-def,dead>, %XMM9<imp-def,dead>, %XMM10<imp-def,dead>, %XMM11<imp-def,dead>, %XMM12<imp-def,dead>, %XMM13<imp-def,dead>, %XMM14<imp-def,dead>, %XMM15<imp-def,dead>, %EFLAGS<imp-def,dead>, %EAX<imp-def>, %ECX<imp-def,dead>, %EDI<imp-def,dead>, %EDX<imp-def,dead>, %ESI<imp-def,dead> 108 ADJCA...

...ad>, %XMM1<imp-def,dead>, > %XMM2<imp-def,dead>, %XMM3<imp-def,dead>, %XMM4<imp-def,dead>, > %XMM5<imp-def,dead>, %XMM6<imp-def,dead>, %XMM7<imp-def,dead>, > %XMM8<imp-def,dead>, %XMM9<imp-def,dead>, %XMM10<imp-def,dead>, > %XMM11<imp-def,dead>, %XMM12<imp-def,dead>, %XMM13<imp-def,dead>, > %XMM14<imp-def,dead>, %XMM15<imp-def,dead>, %EFLAGS<imp-def,dead>, > %EAX<imp-def>, %ECX<imp-def,dead>, %EDI<imp-def,dead>, > %EDX<imp-def,dead>, %ESI<imp-def,dead&gt...

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

...M0<imp-def,dead>, %XMM1<imp-def,dead>, %XMM2<imp-def,dead>, %XMM3<imp-def,dead>, %XMM4<imp-def,dead>, %XMM5<imp-def,dead>, %XMM6<imp-def,dead>, %XMM7<imp-def,dead>, %XMM8<imp-def,dead>, %XMM9<imp-def,dead>, %XMM10<imp-def,dead>, %XMM11<imp-def,dead>, %XMM12<imp-def,dead>, %XMM13<imp-def,dead>, %XMM14<imp-def,dead>, %XMM15<imp-def,dead>, %EAX<imp-def> CALL64pcrel32 <ga:printf> %mreg(78) %mreg(74)<d> %mreg(77)<d> %mreg(79)<d> %mreg(81)<d> %mreg(78)<d> %mreg(6...

...ad>, %XMM1<imp-def,dead>, > %XMM2<imp-def,dead>, %XMM3<imp-def,dead>, %XMM4<imp-def,dead>, > %XMM5<imp-def,dead>, %XMM6<imp-def,dead>, %XMM7<imp-def,dead>, > %XMM8<imp-def,dead>, %XMM9<imp-def,dead>, %XMM10<imp-def,dead>, > %XMM11<imp-def,dead>, %XMM12<imp-def,dead>, %XMM13<imp-def,dead>, > %XMM14<imp-def,dead>, %XMM15<imp-def,dead>, %EAX<imp-def> > CALL64pcrel32 <ga:printf> %mreg(78) %mreg(74)<d> %mreg(77)<d> %mreg > (79)<d> > %mreg(81)<d> %mreg...

...egNum<[24, 28, 28]>; // X86-64 only def XMM8b: Register<"xmm8b">, DwarfRegNum<[25, -2, -2]>; def XMM9b: Register<"xmm9b">, DwarfRegNum<[26, -2, -2]>; def XMM10b: Register<"xmm10b">, DwarfRegNum<[27, -2, -2]>; def XMM11b: Register<"xmm11b">, DwarfRegNum<[28, -2, -2]>; def XMM12b: Register<"xmm12b">, DwarfRegNum<[29, -2, -2]>; def XMM13b: Register<"xmm13b">, DwarfRegNum<[30, -2, -2]>; def XMM14b: Register<"xmm14b">, DwarfRegNum&...

...-def,dead>, > > %XMM2<imp-def,dead>, %XMM3<imp-def,dead>, %XMM4<imp-def,dead>, > > %XMM5<imp-def,dead>, %XMM6<imp-def,dead>, %XMM7<imp-def,dead>, > > %XMM8<imp-def,dead>, %XMM9<imp-def,dead>, %XMM10<imp-def,dead>, > > %XMM11<imp-def,dead>, %XMM12<imp-def,dead>, %XMM13<imp-def,dead>, > > %XMM14<imp-def,dead>, %XMM15<imp-def,dead>, %EAX<imp-def> > > CALL64pcrel32 <ga:printf> %mreg(78) %mreg(74)<d> %mreg(77)<d> %mreg > > (79)<d> > > %mreg(...

...;, >>> %XMM2<imp-def,dead>, %XMM3<imp-def,dead>, %XMM4<imp-def,dead>, >>> %XMM5<imp-def,dead>, %XMM6<imp-def,dead>, %XMM7<imp-def,dead>, >>> %XMM8<imp-def,dead>, %XMM9<imp-def,dead>, %XMM10<imp-def,dead>, >>> %XMM11<imp-def,dead>, %XMM12<imp-def,dead>, %XMM13<imp-def,dead>, >>> %XMM14<imp-def,dead>, %XMM15<imp-def,dead>, %EAX<imp-def> >>> CALL64pcrel32 <ga:printf> %mreg(78) %mreg(74)<d> %mreg(77)<d> %mreg >>> (79)<d> >&gt...

Hi, My understanding of a "dead" register is a def that is never used. However, when I dump the MI after reg alloc on a simple program I see the following sequence: ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12 %r13 %r14

...R11W: > - case X86::R12W: case X86::R13W: case X86::R14W: case X86::R15W: > - case X86::R8B: case X86::R9B: case X86::R10B: case X86::R11B: > - case X86::R12B: case X86::R13B: case X86::R14B: case X86::R15B: > - case X86::XMM8: case X86::XMM9: case X86::XMM10: case X86::XMM11: > - case X86::XMM12: case X86::XMM13: case X86::XMM14: case X86::XMM15: > - return true; > - } > - return false; > -} > - > -inline static bool isX86_64NonExtLowByteReg(unsigned reg) { > - return (reg == X86::SPL || reg == X86::BPL || > - reg == X86::SIL...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

...ormat:vector-uint8;set:Floating > Point Registers;gcc:26;dwarf:26;container-regs:64;#00 > $qRegisterInfo75#ae > $name:xmm10;bitsize:128;offset:595;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:27;dwarf:27;container-regs:65;#00 > $qRegisterInfo76#af > $name:xmm11;bitsize:128;offset:627;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:28;dwarf:28;container-regs:66;#00 > $qRegisterInfo77#b0 > $name:xmm12;bitsize:128;offset:659;encoding:vector;format:vector-uint8;set:Floating > Point Registers;gcc:29;dwarf:29;container-regs:67...

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