search for: mov32ri

...o hear about it. > > If you wonder about the liveness information, you can perform experiments like this (I'm using a NOOP instruction with an implicit use operand to produce some artificial uses). > > $ cat test.mir > name: somefunc > body: | > bb.0: > %0:gr32 = MOV32ri 42 > JB_1 %bb.2, undef implicit $eflags > JMP_1 %bb.2 > > bb.1: > %1:gr32 = MOV32ri 17 > JMP_1 %bb.3 > > bb.2: > NOOP implicit %0 > %1 = COPY %0 > JMP_1 %bb.3 > > bb.3: > NOOP implicit %1 > > > > $ llc...

...t TargetInstrInfo *TII = MF.getTarget().getInstrInfo(); DebugLoc dl; // CALLpcrel32 abort BuildMI(MBB,dl,TII->get(X86::CALLpcrel32)).addExternalSymbol("abort"); // JNE_4 error_label BuildMI(MBB,dl,TII->get(X86::JNE_4)).addExternalSymbol("error_label"); // MOV32ri %eax, 0 BuildMI(MBB,dl,TII->get(X86::MOV32ri),X86::EAX).addImm(0); // CALL32r %eax // BuildMI(MBB,dl,TII->get(X86::CALL32r)).addReg(X86::EAX); MF.insert(I,MBB); } When I tried to dump the code after the insertion, the program enters an infinite loop in the while loop inside Mach...

...92<def> = MOVSDrm <fi#0>, 1, %noreg, 88, %noreg; mem:LD8[%92] FR64:%vreg192 %vreg193<def> = MOVSDrm <fi#0>, 1, %noreg, 24, %noreg; mem:LD8[%89] FR64:%vreg193 %vreg194<def> = MOVSDrm <fi#0>, 1, %noreg, 80, %noreg; mem:LD8[%94] FR64:%vreg194 %vreg195<def> = MOV32ri 8; GR32:%vreg195 %EAX<def> = COPY %vreg195; GR32:%vreg195 WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg196<def> = COPY %ESP; GR32:%vreg196 MOV32mr %vreg196, 1, %noreg, 0, %noreg, %vreg16; mem:ST4[%114] GR32:%vreg1...

...ive Outs: %EAX BB#0: derived from LLVM BB %entry %reg16385<def> = MOV32rm <fi#-2>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-2] GR32:%reg16385 %reg16384<def> = MOV32rm <fi#-1>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-1] GR32:%reg16384 %reg16388<def> = MOV32ri 1; GR32:%reg16388 %reg16392<def> = XOR32ri %reg16385, 4294967294, %EFLAGS<imp-def>; GR32:%reg16392,16385 %reg16391<def> = AND32rr *%reg16392<kill>*, %reg16384, %EFLAGS<imp-def>; GR32:%reg16391,16392,16384 %reg16389<def> = SHR32ri %reg16391, 1...

...er about the liveness information, you can perform > experiments like this (I'm using a NOOP instruction with an implicit use > operand to produce some artificial uses). > > > > $ cat test.mir > > name: somefunc > > body: | > > bb.0: > > %0:gr32 = MOV32ri 42 > > JB_1 %bb.2, undef implicit $eflags > > JMP_1 %bb.2 > > > > bb.1: > > %1:gr32 = MOV32ri 17 > > JMP_1 %bb.3 > > > > bb.2: > > NOOP implicit %0 > > %1 = COPY %0 > > JMP_1 %bb.3 > > > >...

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.

...MOVSDrm <fi#0>, 1, %noreg, 88, %noreg; mem:LD8[%92] FR64:%vreg192 > %vreg193<def> = MOVSDrm <fi#0>, 1, %noreg, 24, %noreg; mem:LD8[%89] FR64:%vreg193 > %vreg194<def> = MOVSDrm <fi#0>, 1, %noreg, 80, %noreg; mem:LD8[%94] FR64:%vreg194 > %vreg195<def> = MOV32ri 8; GR32:%vreg195 > %EAX<def> = COPY %vreg195; GR32:%vreg195 > WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> > %vreg196<def> = COPY %ESP; GR32:%vreg196 > MOV32mr %vreg196, 1, %noreg, 0, %noreg, %vreg16; mem...

...; experiments like this (I'm using a NOOP instruction with an implicit use > operand to produce some artificial uses). > >> > > >> > $ cat test.mir > >> > name: somefunc > >> > body: | > >> > bb.0: > >> > %0:gr32 = MOV32ri 42 > >> > JB_1 %bb.2, undef implicit $eflags > >> > JMP_1 %bb.2 > >> > > >> > bb.1: > >> > %1:gr32 = MOV32ri 17 > >> > JMP_1 %bb.3 > >> > > >> > bb.2: > >> > NOOP impl...

Hi, I had (naively?) expected that the instruction to move immediate to register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, MOV64ri32) would be marked with the flag MCID::MovImm via the X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). I do not see that to be the case. Can someone please tell me if my expectation is flawed? Is there a better/different way to determine to test for m...

...I now I need to sort out details for all the other targets. To start, can someone please advise on the AAarch64 equivalent of these X86 patterns? // Opaque values become mov immediate to register def : Pat<(i64 (opaque imm:$src)), (MOV64ri imm:$src)>; def : Pat<(i32 (opaque imm:$src)), (MOV32ri imm:$src)>; def : Pat<(i16 (opaque imm:$src)), (MOV16ri imm:$src)>; The 'opaque' here is of course hiding the immediate from folding. What I'm looking for is the AAarch64 equivalent to copying the opaque immediate into a register. I promise your help won't be construed as...

...Before Calculate spill weights ***: # Machine code for function CGA_kernel_read: Post SSA Function Live Ins: %P0 in %vreg5, %P1 in %vreg6 Function Live Outs: %P15 0B BB#0: derived from LLVM BB %entry Live Ins: %P0 %P1 16B %vreg6<def> = COPY %P1; IntRegs:%vreg6 48B %vreg8<def> = MOV32ri <ga:@fifo>, pred:%noreg; IntRegs:%vreg8 dbg:../src/getbits.c:46:1 64B %vreg9<def> = LDUBri %vreg8, 1, pred:%noreg; mem:LD1[getelementptr inbounds (%struct.FIFO* @fifo, i32 0, i32 1)] IntRegs:%vreg9,%vreg8 dbg:../src/getbits.c:46:1 80B %vreg10<def> = CMPEQI %vreg9<kill>, 0,...

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

...o do? > > ~Craig > > On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I had (naively?) expected that the instruction to move immediate to >> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >> MOV64ri32) would be marked with the flag MCID::MovImm via the >> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >> >> I do not see that to be the case. >> >> Can someone please tell me if my expectation is flawed? Is the...

...s is causing me some headaches, as far as I can tell, it's not really possible to mix the two using tablegen? In the hardware, every instruction can either take an A register or a B register, in tablegen (as far as I can understand) this is not possible. I ended up creating instructions like MOV32ri (register immediate) MOV32rr (register register) MOV64rr, MOV64ri etc. I've done this for essentially every instruction. This kind of works, but there are issues. It results in unneeded copies between A registers and B registers. If a value is in an A register and the other is in a B, LLVM wi...

...on any instructions What are you trying to do? ~Craig On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I had (naively?) expected that the instruction to move immediate to > register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, > MOV64ri32) would be marked with the flag MCID::MovImm via the > X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). > > I do not see that to be the case. > > Can someone please tell me if my expectation is flawed? Is there a > better/differe...

...; >> DebugLoc dl; >> // CALLpcrel32 abort >> BuildMI(MBB,dl,TII->get(X86::CALLpcrel32)).addExternalSymbol("abort"); >> // JNE_4 error_label >> BuildMI(MBB,dl,TII->get(X86::JNE_4)).addExternalSymbol("error_label"); >> // MOV32ri %eax, 0 >> BuildMI(MBB,dl,TII->get(X86::MOV32ri),X86::EAX).addImm(0); >> // CALL32r %eax >> // BuildMI(MBB,dl,TII->get(X86::CALL32r)).addReg(X86::EAX); >> MF.insert(I,MBB); >> } >> >> When I tried to dump the code after the insertion, the...

I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations where you have small stacks, which is not uncommon for

...;m using a NOOP instruction with an implicit use operand to produce some artificial uses). >>>>>> >>>>>> $ cat test.mir >>>>>> name: somefunc >>>>>> body: | >>>>>> bb.0: >>>>>> %0:gr32 = MOV32ri 42 >>>>>> JB_1 %bb.2, undef implicit $eflags >>>>>> JMP_1 %bb.2 >>>>>> >>>>>> bb.1: >>>>>> %1:gr32 = MOV32ri 17 >>>>>> JMP_1 %bb.3 >>>>>> >>>>>...

...>> On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> I had (naively?) expected that the instruction to move immediate to >>> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >>> MOV64ri32) would be marked with the flag MCID::MovImm via the >>> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >>> >>> I do not see that to be the case. >>> >>> Can someone please tell me if my expec...

...rate more complex instructions, I get lost. Say, I want to insert the following instruction mov eax, 42 then the best I can come up with is Ops.push_back(Chain); Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32)); Ops.push_back(DAG.getConstant(42, MVT::i32)); Chain = DAG.getNode(X86::MOV32ri, DAG.getVTList(MVT::Other), &Ops[0], Ops.size()); But there are a few problems: 3) It seems I am not allowed to use concrete X86 instructions here (at least that's what I think llc's error message "cannot yet select" could mean). Is there an appropriate instruction in ISD? I...