search for: add64ri8

I want to write a pattern that looks something like this: def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst), (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri (VR128:$src, (MOVSDmr addr:$dst, FR64:$src))), imm:3) So I want to convert an unaligned vector store to a scalar store, a shuffle and a scalar store. There are several question I have: - Is the imm:3 syntax correct? Basically I want to hard-code the sh...

On Monday 17 November 2008 14:28, David Greene wrote: > I want to write a pattern that looks something like this: > > def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst), > (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri (VR128:$src, > (MOVSDmr addr:$dst, FR64:$src))), imm:3) > > So I want to convert an unaligned vector store to a scalar store, a shuffle > and a scalar store. I got a little further with this: def : Pat<(unalignedstore (v2f64 VR128:$src), add...

On Nov 17, 2008, at 3:50 PM, David Greene wrote: > On Monday 17 November 2008 14:28, David Greene wrote: >> I want to write a pattern that looks something like this: >> >> def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst), >> (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri >> (VR128:$src, >> (MOVSDmr addr:$dst, FR64:$src))), imm:3) >> >> So I want to convert an unaligned vector store to a scalar store, a >> shuffle >> and a scalar store. > > I got a little further with this: > &g...

...DBG_PHI $rbx, 2 DBG_INSTR_REF 2, 0, !16, !DIExpression(), debug-location !23 ; This is the load from *curptr: renamable $rdi = MOV64rm renamable $r15, 8, renamable $rbx ; Call to ext, CALL64pcrel32 @ext, csr_64, [implicit defs] ; Loop increment: renamable $rbx = nuw nsw ADD64ri8 killed renamable $rbx, 1, debug-instr-number 1 DBG_INSTR_REF 1, 0, !16, !DIExpression(), debug-location !23 CMP64rr renamable $r14, renamable $rbx, implicit-def $eflags JCC_1 %bb.2, 5, implicit $eflags The label "debug-instr-number 1" on the ADD64ri8 identifies the ADD as cor...

Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several

...sign a debug location to the ConstantSDNode for "1". When this constant is used again (as it happens to be in the lowered version of the call to print()) the debugger steps back to the first use of the constant. Here's a snippet of MIR output that illustrates the problem: %19:gr64 = ADD64ri8 %18, 8, implicit-def dead %eflags; GR64:%19,%18 dbg:destroy-after-foreach.swift:2:7 %20:gr32 = MOV32ri64 1; GR32:%20 dbg:destroy-after-foreach.swift:1:44 %21:gr64 = SUBREG_TO_REG 0, killed %20, sub_32bit; GR64:%21 GR32:%20 dbg:destroy-after-foreach.swift:1:44 %rdi = COPY %21; GR64:%21 dbg:destro...

...bg:l8.cpp:6:1 MOV32mr %RSP, 1, %reg0, 20, %reg0, %EDI; mem:ST4[%X] dbg:l8.cpp:6:1 %RAX<def> = MOV64ri <ga:@intDisp>; dbg:l8.cpp:7:1 CALL64r %RAX<kill>, %EDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ...; dbg:l8.cpp:7:1 %RSP<def> = ADD64ri8 %RSP, 24, %EFLAGS<imp-def,dead>; dbg:l8.cpp:7:1 RET; dbg:l8.cpp:7:1 My other questions are: 1. What is the correct way to obtain the runtime values of variables in an abstract form after register allocation? 2. I would like to prevent the generation of the DBG_VALUE instruction but still...

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

...%RSP<imp-def>, %EFLAGS<imp-def,dead>, %RSP<imp-use> > %vreg6<def> = MOV64rm %vreg3, 1, %noreg, 16, %noreg; mem:LD8[%args.0](tbaa=<badref>) GR64:%vreg6,%vreg3 > %vreg5<def> = COPY %vreg3; GR64:%vreg5,%vreg3 > %vreg5<def,tied1> = ADD64ri8 %vreg5<tied0>, 16, %EFLAGS<imp-def,dead>; GR64:%vreg5 > TEST64rr %vreg6, %vreg6, %EFLAGS<imp-def>; GR64:%vreg6 > %vreg9<def> = COPY %vreg6; GR64:%vreg9,%vreg6 > %vreg10<def> = COPY %vreg4; GR64:%vreg10,%vreg4 > %vreg11<def>...

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

On Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

...MachineBasicBlock &MBB, + unsigned StackPtr) { + int32_t Offset = 0; + if (MBBI != MBB.begin()) { + MachineBasicBlock::iterator PI = prior(MBBI); + unsigned Opc = PI->getOpcode(); + if ((Opc == X86::ADD64ri32 || Opc == X86::ADD64ri8 || + Opc == X86::ADD32ri || Opc == X86::ADD32ri8) && + PI->getOperand(0).getReg() == StackPtr){ + Offset += PI->getOperand(2).getImm(); + MBB.erase(PI); + } + } + return Offset; +} + Seems like the previous chunk can be changed to use this function with...