similar to: [LLVMdev] MachineSink and EFLAGS

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:

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

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

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

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

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 have with CMOV_FR64). Wouldn't it be safe then to not set the live-in

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

Hello LLVM-dev, I think I've found an issue with the MachineSink optimization on a program that uses setjmp. It looks like MachineSink will happily move a machine instruction into a following machine basic block (not necessarily a successor), even when that later block can be reached through a setjmp. Here is some example debug output from llc that I'm seeing: Sinking along critical

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)

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

Hi. This is a known gcc bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53670). GCC 4.5 can't compile clang 3.1 On 13 September 2012 06:53, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: > Hi all, > > I think it's Gentoo's bug, but I want to know if anyone has the same > issue here. I am compiling LLVM trunk on Gentoo (gcc 4.5.2), and I get > error

Hi Duncan. Probably it depends on exact gcc version and possibly assert/noassert build option. I've got this problem with gcc 4.5.2 on 64-bit Suse (I don't remember whether assertions were enabled). On 17 September 2012 21:12, Duncan Sands <baldrick at free.fr> wrote: > Hi Sergey, > > >> This is a known gcc bug >>

Hi Sergey, > This is a known gcc bug > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53670). GCC 4.5 can't > compile clang 3.1 are you sure? I built the LLVM/clang-3.1 release binaries for ubuntu 64 bits using gcc-4.5. Ciao, Duncan. > > On 13 September 2012 06:53, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: >> Hi all, >> >> I think

I'm looking at fixing some layering violations in LLVM & came across a few in the CodeView handling, specifically: lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers I guess MC could be made dependent on DebugInfoCodeView? But probably these things should be sunk into BinaryFormat as is the case for DWARF features used by MC? include/llvm/Object/COFF.h includes

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",

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,

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

Someone internally's been dabbling with turning on some of Google's build system's stricter header checking modes - and they caught these (you can check the internal code review 184305506 for the original where I'm pulling things out from). & yeah, fair question about the modules builds - I don't fully understand what they catch and don't catch. I suspect it's a

Yes, some of the headers and stuff that are just raw structure definitions and enums could probably be sunk into BinaryFormat.. How'd you find this? Curious why it hasn't been breaking in modules builds for a long time. On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > I'm looking at fixing some layering violations in LLVM & came across a