search for: mov64ri

...mem:LD8[GOT] GR64:%vreg0 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg1 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; mem:ST8[@p](tbaa=!"any pointer") GR64:%vreg1,%vreg0 64B %vreg2<def> = MOV64ri 12345123400; GR64:%vreg2 80B MOV64mr %vreg0, 1, %noreg, 0, %noreg, %vreg2; mem:ST8[@val](tbaa=!"long long") GR64:%vreg0,%vreg2 96B %RDI<def> = COPY %vreg2; GR64:%vreg2 112B TCRETURNdi64 <ga:@xtr>, 0, <regmask>, %RSP<imp-use>, %RDI...

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

...> 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], > %noreg; mem:LD8[GOT] GR64:%vreg1 > 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; > mem:ST8[@p](tbaa=!"any pointer") GR64:%vreg1,%vreg0 > 64B %vreg2<def> = MOV64ri 12345123400; GR64:%vreg2 > 80B MOV64mr %vreg0, 1, %noreg, 0, %noreg, %vreg2; > mem:ST8[@val](tbaa=!"long long") GR64:%vreg0,%vreg2 > 96B %RDI<def> = COPY %vreg2; GR64:%vreg2 > 112B TCRETURNdi64 <ga:@xtr>, 0, <regmask>, %RSP&...

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 move immediate to reg...

...EI::insertPrologEpilogCode: === >> before emitEpilogue - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> - insn: PROLOG_LABEL <MCSym=.Ltmp2> - insn: %RBP<def> = MOV64rr %RSP - insn: PROLOG_LABEL <MCSym=.Ltmp3> - insn: %RDI<def> = MOV64ri64i32 60910096 - insn: %RAX<def> = MOV64ri <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... - insn: RET * PEI::insertPrologEpilogCode: === &lt...

...%vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], > > %noreg; mem:LD8[GOT] GR64:%vreg1 > > 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; > > mem:ST8[@p](tbaa=!"any pointer") GR64:%vreg1,%vreg0 > > 64B %vreg2<def> = MOV64ri 12345123400; GR64:%vreg2 > > 80B MOV64mr %vreg0, 1, %noreg, 0, %noreg, %vreg2; > > mem:ST8[@val](tbaa=!"long long") GR64:%vreg0,%vreg2 > > 96B %RDI<def> = COPY %vreg2; GR64:%vreg2 > > 112B TCRETURNdi64 <ga:@xtr>, 0, &l...

...opaque constants. It's going well for the IR and x86, but 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 i...

On Aug 26, 2010, at 12:59 PMPDT, Eric Christopher wrote: > On Aug 26, 2010, at 12:25 PM, Yuri wrote: >> On 08/26/2010 11:53, Eric Christopher wrote: >>> Could you get it to print out the instruction when it happens? >>> (just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo

...gEpilogCode: === >> before emitEpilogue > - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> > - insn: PROLOG_LABEL <MCSym=.Ltmp2> > - insn: %RBP<def> = MOV64rr %RSP > - insn: PROLOG_LABEL <MCSym=.Ltmp3> > - insn: %RDI<def> = MOV64ri64i32 60910096 > - insn: %RAX<def> = MOV64ri > <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> > - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, > %RDI<imp-def,dead>, %RSP<imp-use>, ... > - insn: RET > * PEI::inser...

...ALESCING ********** > ********** Function: caller > ********** JOINING INTERVALS *********** > entry: > 64B %RDI<def> = COPY %vreg0; GR64:%vreg0 > Considering merging %vreg0 with %RDI > Can only merge into reserved registers. > Remat: %RDI<def> = MOV64ri 12345123400 > Shrink: [32r,64r:0) 0 at 32r > Shrunk: [32r,48r:0) 0 at 32r > Trying to inflate 0 regs. > ********** INTERVALS ********** > %vreg0 = [32r,48r:0) 0 at 32r > RegMasks: 80r > > Jakob, what does "can only merge into reserved registers" mean in this in...

...%R11<def> = LEA64r %RSP, 1, %noreg, -40040, %noreg CMP64rm %R11, %noreg, 1, %noreg, 40, %GS, %EFLAGS<imp-def> JA_1 <BB#0>, %EFLAGS<imp-use> Successors according to CFG: BB#3 BB#0 BB#3: Predecessors according to CFG: BB#4 %R10<def> = MOV64ri 40040 %R11<def> = MOV64ri 32 CALL64pcrel32 <es:__morestack>, %RSP<imp-use> MORESTACK_RET Successors according to CFG: BB#0 BB#0: derived from LLVM BB %0 Predecessors according to CFG: BB#3 BB#4 %EAX<def> = MOV32ri 40040; flags: FrameS...

...ig > > 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...

...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 will do a copy between registers to make sure both registers are the...

...ion: ********** SIMPLE REGISTER COALESCING ********** ********** Function: caller ********** JOINING INTERVALS *********** entry: 64B %RDI<def> = COPY %vreg0; GR64:%vreg0 Considering merging %vreg0 with %RDI Can only merge into reserved registers. Remat: %RDI<def> = MOV64ri 12345123400 Shrink: [32r,64r:0) 0 at 32r Shrunk: [32r,48r:0) 0 at 32r Trying to inflate 0 regs. ********** INTERVALS ********** %vreg0 = [32r,48r:0) 0 at 32r RegMasks: 80r Jakob, what does "can only merge into reserved registers" mean in this instance. I don't see any reason for i...

...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/different way to determine...

...ptions, Yes, thanks. It's a slightly weird hack, but it works perfectly. :-) "-debug-only=jit" generates just a binary dump, like this: JIT: Binary code: JIT: 00000000: 4a04b848 000000ca 048b0000 c320 whereas "-debug-only=x86-emitter" generates this: %RAX<def> = MOV64ri <ga:poo1> %EAX<def> = MOV32rm %RAX<kill>, 1, %reg0, 0, Mem:LD(4,4) [poo1 + 0] RET %EAX<imp-use,kill> which may be more useful. Can I put in a request some machine-independent names for the debug dumps? It's "x86-emitter", "alpha-emitter", "x86...

...= >> before emitEpilogue >> - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> >> - insn: PROLOG_LABEL <MCSym=.Ltmp2> >> - insn: %RBP<def> = MOV64rr %RSP >> - insn: PROLOG_LABEL <MCSym=.Ltmp3> >> - insn: %RDI<def> = MOV64ri64i32 60910096 >> - insn: %RAX<def> = MOV64ri <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> >> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> - insn: RET >> * PEI::insert...

On Aug 5, 2013, at 8:34 AM, Maurice Marks <maurice.marks at gmail.com> wrote: > Are you sure that's it? I commented that block out, rebuilt llvm 3.3, and it still duplicates the constant. > My concern is that long constant loads increase code size and if they can be avoided by better targeting it would be a win. My project's application of llvm tends to use a lot of long

...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...

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>