[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 04/17] x86emul: support {, V}{, U}COMIS{S, D}
>>> On 01.03.17 at 15:16, <andrew.cooper3@xxxxxxxxxx> wrote: > On 28/02/17 12:51, Jan Beulich wrote: >> @@ -5468,6 +5468,55 @@ x86_emulate( >> state->simd_size = simd_none; >> break; >> >> + CASE_SIMD_PACKED_FP(, 0x0f, 0x2e): /* ucomis{s,d} xmm/mem,xmm */ >> + CASE_SIMD_PACKED_FP(_VEX, 0x0f, 0x2e): /* vucomis{s,d} xmm/mem,xmm */ >> + CASE_SIMD_PACKED_FP(, 0x0f, 0x2f): /* comis{s,d} xmm/mem,xmm */ >> + CASE_SIMD_PACKED_FP(_VEX, 0x0f, 0x2f): /* vcomis{s,d} xmm/mem,xmm */ >> + if ( vex.opcx == vex_none ) >> + { >> + if ( vex.pfx ) >> + vcpu_must_have(sse2); >> + else >> + vcpu_must_have(sse); >> + get_fpu(X86EMUL_FPU_xmm, &fic); >> + } >> + else >> + { >> + host_and_vcpu_must_have(avx); >> + get_fpu(X86EMUL_FPU_ymm, &fic); >> + } > > This is starting to become a common sequence. Is there any sensible way > to factor it out in a non-macro way, to avoid the compiler instantiating > it at the top of many basic blocks? While I would have wanted to, I couldn't think of one which wouldn't be almost as ugly as the redundancy. The main problem being - as you likely understand yourself - that we'd need parameters for all the used features as well as all the involved X86EMUL_FPU_* values. >> + opc = init_prefixes(stub); >> + opc[0] = b; >> + opc[1] = modrm; >> + if ( ea.type == OP_MEM ) >> + { >> + rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, vex.pfx ? 8 : 4, >> + ctxt); >> + if ( rc != X86EMUL_OKAY ) >> + goto done; >> + >> + /* Convert memory operand to (%rAX). */ >> + rex_prefix &= ~REX_B; >> + vex.b = 1; >> + opc[1] &= 0x38; >> + } >> + fic.insn_bytes = PFX_BYTES + 2; >> + opc[2] = 0xc3; >> + >> + copy_REX_VEX(opc, rex_prefix, vex); >> + invoke_stub(_PRE_EFLAGS("[eflags]", "[mask]", "[tmp]"), >> + _POST_EFLAGS("[eflags]", "[mask]", "[tmp]"), >> + [eflags] "+g" (_regs._eflags), >> + [tmp] "=&r" (cr4 /* dummy */), "+m" (*mmvalp), > > This is latently dangerous. It would be better to have an explicit > "unsigned long dummy;", which the compiler will perfectly easily elide > during register scheduling. The thing I want to avoid as much as possible are these ugly, improperly indented extra scopes following case labels. If putting a dummy variable into the whole switch() scope is okay with you, I could live with that. But then again I don't see the danger here - there's no imaginable use for cr4 in this piece of code. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |