search for: x86instrcompil

...g the metadata bits). As a side note, GCC does emit the second > snippet as expected. > > > Looking at the TableGen files I found two problems: > > 1. The AND of the address with 0xffffffff is replaced with > SUBREG_TO_REG(MOV32rr (EXTRACT_SUBREG ...)) in > lib/Target/X86/X86InstrCompiler.td (line 1326). That MOV32rr emits an > explicit mov instruction later. I think I need to replace this with > (i32 (EXTRACT_SUBREG ...)) to get rid of the mov, but that produces a > 32-bit value, which leads me to the next, more general problem: > > 2. The x86 backend currently...

...s zero-extended, effectively ignoring the metadata bits). As a side note, GCC does emit the second snippet as expected. Looking at the TableGen files I found two problems: 1. The AND of the address with 0xffffffff is replaced with SUBREG_TO_REG(MOV32rr (EXTRACT_SUBREG ...)) in lib/Target/X86/X86InstrCompiler.td (line 1326). That MOV32rr emits an explicit mov instruction later. I think I need to replace this with (i32 (EXTRACT_SUBREG ...)) to get rid of the mov, but that produces a 32-bit value, which leads me to the next, more general problem: 2. The x86 backend currently does not support derefer...

...y, how to return the value when working with MachineInst? First, I have defined an instrinsic in "Intrinsics.td": _def int_antivm : Intrinsic<[llvm_i1_ty], [], [], "llvm.antivm">;_ Then I want to lower it in the X86 backend, so I defined a pseudo instruction in "X86InstrCompiler.td": _let usesCustomInserter = 1, Defs = [EFLAGS] in {_ _def ANTIVM : PseudoI<(outs), (ins), [(int_antivm)]>;_ _}_ I wrote my custom inserter: _MachineBasicBlock *_ _X86TargetLowering::EmitANTIVMWithCustomInserter(_ _ MachineInstr *MI,_ _ MachineBasicBlock *MBB) const {_ _ // So...

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 of normal branch instructions there is no specific reset inst...

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

...t going through a register. The main trouble here is that the X86 backend appears to respect LLVM memory model instead of the x86-TSO memory model, and may reorder instructions. In order to prevent illegal reordering of atomic accesses, the backend converts atomic accesses to pseudo-instructions in X86InstrCompiler.td (RELEASE_MOV* and ACQUIRE_MOV*) that are opaque to most of the rest of the backend, and only lowers those at the very end of the pipeline. I have decided to follow the same approach, just adding some more RELEASE_* pseudo-instructions rather than trying to find every possibly misbehaving part...

On Feb 26, 2011, at 1:36 PM, Joerg Sonnenberger wrote: > On Sat, Feb 26, 2011 at 01:07:39PM -0800, Jakob Stoklund Olesen wrote: >> >> You may want to consider using xorl+decl instead. It is also three >> bytes, and there are no false dependencies. The xor idiom is recognized >> by processors as old as Pentium 4 as having no dependencies. > > Any examples of how

On Sat, Feb 26, 2011 at 01:07:39PM -0800, Jakob Stoklund Olesen wrote: > > On Feb 25, 2011, at 7:27 PM, Joerg Sonnenberger wrote: > > > I'm trying to add a X86 pattern to turn > > movl $-1, %eax > > into > > orl $-1, $eax > > Please make sure to measure the performance impact of doing this. You > are creating a false dependency on the last

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 understand the remark about resetting EFLAGS. What kind of reset is meant? In case of normal branch instructions there is no specific...

...))>; Hm. Right. This gives the me first set of size peep hole optmisations as attached. I didn't add the above rule for 64bit builds, since it is larger than the to-be-figured out OR32rmi8 / OR64rmi8. Joerg -------------- next part -------------- A non-text attachment was scrubbed... Name: X86InstrCompiler.td.diff Type: text/x-diff Size: 876 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110227/94a8caea/attachment.diff>

Try adding ECX to the Defs of this part of lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have a Windows machine to test myself. let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), "# win32 fptoui", [(X86WinFTOL RFP32:$sr...

...on't think that's going to work. On Fri, Jul 19, 2013 at 12:24 AM, Peter Newman <peter at uformia.com> wrote: > Thank you, I'm trying this now. > > > On 19/07/2013 5:23 PM, Craig Topper wrote: > > Try adding ECX to the Defs of this part of > lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have a > Windows machine to test myself. > > let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { > def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), > "# win32 fptoui", >...

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

...> > On Fri, Jul 19, 2013 at 12:24 AM, Peter Newman <peter at uformia.com> wrote: > >> Thank you, I'm trying this now. >> >> >> On 19/07/2013 5:23 PM, Craig Topper wrote: >> >> Try adding ECX to the Defs of this part of >> lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have a >> Windows machine to test myself. >> >> let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { >> def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), >> "# win32 fptoui",...

I'm working on defining the instructions and implementing the lowering code for a Z80 backend. For now, the backend supports only the native CPU-supported datatypes, which are 8 and 16 bits wide (i.e. no 32 bit long, float, ... yet). So far, a lot of the simple stuff like immediate loads and return values is very straightforward, but now I got stuck with ISD::TRUNCATE, as in:

Thank you, I'm trying this now. On 19/07/2013 5:23 PM, Craig Topper wrote: > Try adding ECX to the Defs of this part of > lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have > a Windows machine to test myself. > > let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { > def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), > "# win32 fptoui", >...

...at 12:24 AM, Peter Newman <peter at uformia.com > <mailto:peter at uformia.com>> wrote: > > Thank you, I'm trying this now. > > > On 19/07/2013 5:23 PM, Craig Topper wrote: >> Try adding ECX to the Defs of this part of >> lib/Target/X86/X86InstrCompiler.td like I've done below. I don't >> have a Windows machine to test myself. >> >> let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { >> def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), >> "# win3...

...>> <mailto:peter at uformia.com>> wrote: >> >> Thank you, I'm trying this now. >> >> >> On 19/07/2013 5:23 PM, Craig Topper wrote: >>> Try adding ECX to the Defs of this part of >>> lib/Target/X86/X86InstrCompiler.td like I've done below. I >>> don't have a Windows machine to test myself. >>> >>> let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { >>> def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), >>>...

...oklund Olesen; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MachineSink and EFLAGS 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 understand the remark about resetting EFLAGS. What kind of reset is meant? In case of normal branch instructions there is no specific...

Oh, excellent point, I agree. My bad. Now that I'm not assuming those are the sqrt, I see the sqrtpd's in the output. Also there are three fptoui's and there are 3 call instances. (Changing subject line again.) Now it looks like it's bug #13862 On 19/07/2013 4:51 PM, Craig Topper wrote: > I think those calls correspond to this > > %110 = fptoui double %109 to i32