search for: eflage

No need to duplicate maintenance of export flag computation between old and new style handshakes. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/connections.c | 120 +++++++++++++++++++++--------------------------------- 1 file changed, 47 insertions(+), 73 deletions(-) diff --git a/src/connections.c b/src/connections.c index 8dc1925..f9edea7 100644 --- a/src/connections.c +++

Simple refactoring. --- generator/states-newstyle-opt-export-name.c | 12 +++++------ generator/states-newstyle-opt-go.c | 13 ++++++------ generator/states-oldstyle.c | 10 +++------- lib/flags.c | 22 +++++++++++++++++++++ lib/internal.h | 5 +++++ 5 files changed, 42 insertions(+), 20 deletions(-) diff

On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote: > Hi, Bill and Jakob. > > I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction? > > I also don't

Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. For an example we can look no further than the actual test which has been disabled after the fix

Thanks for spelling it out, now I understand. On Jun 5, 2011, at 6:11 AM, Galanov, Sergey wrote: > Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. This actually looks like a

Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are clobbering EFLAGS on x86_64. This is inconvenient when the status of bit 9 (IF), which controls interrupts, changes. Here's a simple test program. Assume that the external function foo() modifies the IF bit in EFLAGS. --- #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void)

Per recent discussion here: https://www.redhat.com/archives/libguestfs/2019-May/thread.html#00175

Hello, Here is one question regarding the LLVM TableGen: Which file in the llvm/lib/Target/X86 folder describes how the bits in the EFLAGS register are modified by the x86 instructions? For example, in the "X86InstrInfo.td" file, lines 2134-2135, it says: let SchedRW = [WriteALU], Defs = [EFLAGS], Uses = [EFLAGS] in { def CLC : I<0xF8, RawFrm, (outs), (ins), "clc",

I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not sure this patch to fix it ever got committed: http://reviews.llvm.org/D6629 On Wed, Jul 29, 2015 at 3:11 PM, Michael Hordijk <hoffbrinkle at hotmail.com> wrote: > > Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are > clobbering EFLAGS on x86_64. This is inconvenient when the

--- tests/Makefile.am | 3 + tests/test-eflags.sh | 222 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 225 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index a01c47c..173d622 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -282,6 +282,9 @@ test_oldstyle_LDADD = libtest.la $(LIBGUESTFS_LIBS) endif HAVE_LIBGUESTFS +# Test export flags. +TESTS

On Jun 2, 2011, at 12:58 PM, Bill Wendling wrote: > On Jun 2, 2011, at 3:53 AM, Galanov, Sergey wrote: > >> Hi Bill. >> >> Thank you very much! Now I see my understanding was incorrect :) A dependence from a single physreg-defining instruction (like CMP or TEST) is allowed to be shared in several instructions unless that register is not clobbered (and this is what we

Hi, Bill and Jakob. I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction? I also don't understand the remark about resetting EFLAGS. What kind of reset is meant? In case

# HG changeset patch # User Carl-Daniel Hailfinger <Carl-Daniel.Hailfinger@inf.h-brs.de> # Date 1474903734 -7200 # Mon Sep 26 17:28:54 2016 +0200 # Node ID dbd1ea0a401cedcfa426097a289d852971b14f1e # Parent d7d5078d08c711032837dcac79a4450226ec2ce5 nbdkit: Fix flags in old-style connection diff -r d7d5078d08c7 -r dbd1ea0a401c src/connections.c --- a/src/connections.c Sun Sep 25 05:04:02

Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are clobbering EFLAGS on x86_64. This is inconvenient when the status of bit 9 (IF), which controls interrupts, changes. Here's a simple test program. Assume that the external function foo() modifies the IF bit in EFLAGS. #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void) {

Until the next few patches expose and implement new callbacks for filters and plugins, our initial implementation for NBD_CMD_CACHE is to just blindly advertise the feature, and call into .pread with an ignored buffer. Note that for bisection reasons, this patch treats any use of a filter as a forced .can_cache of false to bypass the filter's caching; once all affected filters are patched to

Hello. I am not sure this is the right place to ask but here is my question. About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believe and so not available to the general public :)) Some discussion can be found here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100531/102160.html. Unfortunately, no

Hi Bill. Thank you very much! Now I see my understanding was incorrect :) A dependence from a single physreg-defining instruction (like CMP or TEST) is allowed to be shared in several instructions unless that register is not clobbered (and this is what we have with CMOV_FR64). Wouldn't it be safe then to not set the live-in flag in EmitLoweredSelect for instructions which are marked as

Hello llvm-dev list, i am implementing an X86 Machine Pass that at some point needs to push/pop eflags on the stack. This pass is hooked at preRegAlloc and LLVM is 3.7.0. I got two big problems: 1) I didn't found a way to emit a pushfq instruction in a clean way, i.e. with BuildMI(*MBB, MI, DL, TII.get(X86::PUSHF64)). Even if both EFLAGS and RSP are added to the MBB liveins, the Machine

Hi ! I'm trying to modify the code in a machine function pass… I added a new basicblock and I want to add a jump to an another BB from my new BB. Here is my code : bool Obfuscation::runOnMachineFunction(MachineFunction &MF) { MachineBasicBlock *newEntry = MF.CreateMachineBasicBlock(); MF.insert(MF.begin(), newEntry); std::vector<MachineBasicBlock*> origBB;

On Jun 1, 2011, at 9:18 AM, Galanov, Sergey wrote: > Hello. > > I am not sure this is the right place to ask but here is my question. About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believe and so not available to the general public J) > Some discussion can be found here: