search for: sahf

...he instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not return after generating it's code, so the normal compare is also generated! As far as I can tell it should return right after this: BuildMI(BB, X86::SAHF, 1); instead it falls through and goes on to generate the normal compare instruction... Am I right? m.

...become the default X86 isel. > The case which emits code for the special case of comparing against constant > 0.0 does not return after generating it's code, so the normal compare is also > generated! As far as I can tell it should return right after this: > > BuildMI(BB, X86::SAHF, 1); > > instead it falls through and goes on to generate the normal compare > instruction... Am I right? Nope. It's emitting a compare against zero with fucomi instead of ftst. fucomi is a PPRO+ instruction that deposits the result of the comparison into the integer condition cod...

Author: fvdl Repository: /hg/zfs-crypto/gate Revision: 76e12e96d15a61404ca01318739d398fb9419e5c Log message: 6219321 amd64 kernel must emulate lahf and sahf instructions Files: update: usr/src/uts/i86pc/os/trap.c update: usr/src/uts/intel/ia32/sys/psw.h

...>> The case which emits code for the special case of comparing against >> constant 0.0 does not return after generating it's code, so the normal >> compare is also generated! As far as I can tell it should return right >> after this: >> >> BuildMI(BB, X86::SAHF, 1); >> >> instead it falls through and goes on to generate the normal compare >> instruction... Am I right? > > Nope. It's emitting a compare against zero with fucomi instead of ftst. > fucomi is a PPRO+ instruction that deposits the result of the comparison &gt...

...x,76E4560h 17160440 mov dword ptr [esp],eax 17160443 call HueVMReadCommands_LLVMReadVoxel (19BB229h) 17160448 fsub dword ptr ds:[161D6280h] 1716044E fabs 17160450 fst qword ptr [esp+14h] 17160454 ftst 17160456 fstp st(0) 17160458 fnstsw ax 1716045A sahf 1716045B fldz 1716045D fchs 1716045F fld qword ptr [esp+14h] 17160463 fucomip st,st(1) 17160465 fstp st(0) 17160467 jbe 17160498 1716046D mov eax,76E4F60h 17160472 mov dword ptr [esp+0Ch],eax 17160476 fld qword ptr [esp+14h] 1716047A fstp...

...omehow?"), function AddLegalizedOperand, file /usr/home/llvm/obj/../lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 79. .text .align 16 .globl test1 .type test1, @function test1: fldl 4(%esp) ftst fstp %st(0) fnstsw sahf setne %al movzbl %al, %eax #FP_REG_KILL ret Abort trap (core dumped) FAIL: /usr/home/llvm/obj/../test/Regression/CodeGen/X86/fast-cc-pass-in-regs.ll: Does not have a RUN line Running /usr/home/llvm/obj/../test/Regression/Debugger/dg.exp ... FAIL: /usr/home/llvm/ob...

.... It seems consistent with gas's size suffixes, but I'm open to other ideas. Normal (non-xray) ISel should never produce this instruction, so we don't need any SDAG patterns for it. You should be able to look at existing rare x86 instructions that don't have SDAG nodes, like PUSHF, SAHF, CPUID, etc to see the minimal amount of tablegen you need to add. On Thu, Jul 14, 2016 at 4:06 AM, Dean Michael Berris <dberris at google.com> wrote: > Hi llvm-dev, > > In the review of the LLVM-side changes to support XRay (which is now > upstream as http://reviews.llvm.org/rL...

...2-bit rw- Backtrace: =>1 0x7fdf635d (0x7fdf635d) err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file DLL\MSVBVM60.dbg ("DLL\\MSVBVM60.dbg") 2 0x66053bd6 in msvbvm60 (+0x53bd6) (0x66053bd6) 3 0x66059efd in msvbvm60 (+0x59efd) (0x66059efd) 4 0x00000000 (0x00000000) 0x7fdf635d: sahf Modules: Module Address Debug info Name (83 modules) PE 0x00400000-005ee000 Deferred atwin2k2 PE 0x16b00000-16b50000 Deferred atvbs2k3 PE 0x17810000-1781a000 Deferred assubclass PE 0x184c0000-184c8000 Deferred asw...

Hello, I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work with the X86ISelPattern, but I'm having some difficulties understanding what needs to be done. I assume I have to add new nodetypes for the FP instructions to SelectionDAGNodes.h, and make nodes for these in SelectionDAGLowering::visitCall when I find the intrinsic... The part I don't quite

Hi llvm-dev, In the review of the LLVM-side changes to support XRay (which is now upstream as http://reviews.llvm.org/rL275367) we hit one particular case where we had to hack around the fact that we have no way to force the emission of a short relative jump. It's even come up that jump relaxation can come in and (at least with clang -O0) relax jumps to use the longer version of the jump

...n benefit is the tighter encoding of rdfsbase, which seems very slim. Not covered in this are tuning decisions. I think we can benefit from some variance in this area between implementations; it should not affect correctness. 32-bit support is also a separate matter. * Level A CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 This is one step above the K8 baseline and corresponds to a mainline CPU model ca. 2008 to 2011. It is also implemented by recent-ish generations of Intel Atom server CPUs (although I haven't tested the latest version). A 32-bit variant would have to list...

...as I have put it up for review. As far as I'm aware, the bugfix should be relatively version-agnostic, so you should not have too much trouble backporting it. The solution basically works like this: * Model FPSW (the FPU status word) as a register. * Add ISel patterns for the FCOM*, FNSTSW and SAHF instructions. * During Legalize/Lowering, build a node sequence to transport the comparison result from FPSW into EFLAGS. The patch itself is already finished, but I want to add a few test cases before submitting it (probably during the weekend if I find the time). Cheers, Christoph Am 05.04.201...

...E_FFXSR (1*32+25) /* FFXSR instruction optimizations */ #define X86_FEATURE_RDTSCP (1*32+27) /* RDTSCP */ #define X86_FEATURE_LM (1*32+29) /* Long Mode (x86-64) */ #define X86_FEATURE_3DNOWEXT (1*32+30) /* AMD 3DNow! extensions */ @@ -93,7 +94,6 @@ #define X86_FEATURE_LAHF_LM (6*32+ 0) /* LAHF/SAHF in long mode */ #define X86_FEATURE_CMP_LEGACY (6*32+ 1) /* If yes HyperThreading not valid */ #define X86_FEATURE_SVME (6*32+ 2) /* Secure Virtual Machine */ -#define X86_FEATURE_FFXSR (6*32+25) /* FFXSR instruction optimizations */ #define cpu_has(c, bit) test_bit(bit, (c)->...

Hello there, I recently started working on the LLVM backend for a target that doesn't support x87 instructions. Currently, I am in the process of completely disabling some x87 instructions such as fcomi, fcompi,... for a specific sub-target. I also do not have SSE enabled for my sub-target, and llvm resorts to fcomi* instructions for FP compare instructions. Is there a way to bypass the

Is it intentional that - under SVM, 32-bit guests can freely set EFER.LME - under VMX, 32-bit guests can''t access EFER at all? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...sions 4.2 */ +#define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */ /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */ #define X86_FEATURE_XSTORE (5*32+ 2) /* on-CPU RNG present (xstore insn) */ @@ -94,6 +100,15 @@ #define X86_FEATURE_LAHF_LM (6*32+ 0) /* LAHF/SAHF in long mode */ #define X86_FEATURE_CMP_LEGACY (6*32+ 1) /* If yes HyperThreading not valid */ #define X86_FEATURE_SVME (6*32+ 2) /* Secure Virtual Machine */ +#define X86_FEATURE_EXTAPICSPACE (6*32+ 3) /* Extended APIC space */ +#define X86_FEATURE_ALTMOVCR (6*32+ 4) /* LOCK MOV CR access...

...g fmuls .LCPI0_0 fldz fchs fxch %st(1) fucompp fnstsw %ax # kill: AX<def> AX<kill> EAX<def> # kill: AH<def> AH<kill> EAX<kill> sahf sete %al movzbl %al, %eax retl .Ltmp0: .size main, .Ltmp0-main .cfi_endproc .type g, at object # @g .section .rodata,"a", at progbits .globl g .align 8 g: .quad 1...

On 7/23/19 8:42 PM, John McCall via llvm-dev wrote: > > On 21 Jul 2019, at 12:29, James Y Knight via llvm-dev wrote: > > Yes, indeed! > > The SBCL lisp compiler (not llvm based) used to emit functions > which would > return either via ret to the usual instruction after the call, or > else load > the return-address from the stack, then jump 2

...t; > > Not covered in this are tuning decisions. I think we can benefit from > > some variance in this area between implementations; it should not affect > > correctness. 32-bit support is also a separate matter. > > > > * Level A > > > > CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 > > > > This is one step above the K8 baseline and corresponds to a mainline CPU > > model ca. 2008 to 2011. It is also implemented by recent-ish > > generations of Intel Atom server CPUs (although I haven't tested the > > late...

...ode, but comes at a high cost. First, we must store the flags to the stack and reload them. Second, this causes the stack pointer to be adjusted dynamically, requiring a frame pointer be used for referring to temporaries spilled to the stack, etc. On newer x86 processors we can use the `lahf` and `sahf` instructions to save all of the flags besides the overflow flag in a register rather than on the stack. We can then use `seto` and `add` to save and restore the overflow flag in a register. Combined, this will save and restore flags in the same manner as above but using two registers rather than t...