search for: gr64

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

...to have at this relatively high level. At the machine level it looks like it is the register coalescer that is duplicating the constant. It transforms 0B BB#0: derived from LLVM BB %entry 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, <ga:@val>[TF=5], %noreg; 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 123451234...

...:$src2, i64:$src))]>; How does tablegen+codegen ensure that dst and src2 are the same register? I see that the assembly/disassembly string assumes this is the case. Also, it uses i64:$src which is an i64 and not a GPR. What is the distinction there? X86 does this differently. src1 and src2 are GR64 registers. def IMUL64rr : RI<0xAF, MRMSrcReg, (outs GR64:$dst), (ins GR64:$src1, GR64:$src2), "imul{q}\t{$src2, $dst|$dst, $src2}", [(set GR64:$dst, EFLAGS, (X86smul_flag GR64:$src1,...

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

...el. > > At the machine level it looks like it is the register coalescer that > is duplicating the constant. It transforms > > 0B BB#0: derived from LLVM BB %entry > 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, > <ga:@val>[TF=5], %noreg; 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<de...

...(ins GR32:$src1, GR32:$src2), > "crc32{l} \t{$src2, $src1|$src1, $src2}", > [(set GR32:$dst, > - (int_x86_sse42_crc32_32 GR32:$src1, GR32:$src2))]>; > - def CRC64m8 : SS42FI<0xF0, MRMSrcMem, (outs GR64:$dst), > + (int_x86_sse42_crc32_32_32 GR32:$src1, GR32:$src2))]>; > + def CRC32r64m8 : SS42FI<0xF0, MRMSrcMem, (outs GR64:$dst), > (ins GR64:$src1, i8mem:$src2), > "crc32{b} \t{$src2, $src1|$src1, $src2}&qu...

...t seems to works in -O0, but in -O1, -O2 and -O3, I got this error (+ the dump of the function): > > # Machine code for function foo: Post SSA > Function Live Ins: %RDI in %vreg7 > > BB#0: derived from LLVM BB %entry > Live Ins: %RDI > %vreg7<def> = COPY %RDI; GR64:%vreg7 > %vreg1<def> = MOV64rm %vreg7, 1, %noreg, 8, %noreg; mem:LD8[%args.03](tbaa=<badref>) GR64:%vreg1,%vreg7 > TEST64rr %vreg1, %vreg1, %EFLAGS<imp-def>; GR64:%vreg1 > JE_4 <BB#3>, %EFLAGS<imp-use,kill> > Successors according to...

...ber RDX when it should be set up for the call? I tried running the final IR->x86 lowering with -print-after-all, and it appears all is well after 'Two-Address instruction pass': MOV32mi <fi#0>, 1, %noreg, 0, %noreg, 1; mem:ST4[%val] %vreg3<def> = MOV64ri64i32 4; GR64:%vreg3 %R8<def> = COPY %vreg3; GR64:%vreg3 INLINEASM <es:> [sideeffect] [attdialect], $0:[reguse], %R8 %vreg4<def> = LEA64r <fi#0>, 1, %noreg, 0, %noreg; GR64:%vreg4 %R10<def> = COPY %vreg4; GR64:%vreg4 INLINEASM <es:> [sideeffect] [attdi...

...chine level it looks like it is the register coalescer that > > is duplicating the constant. It transforms > > > > 0B BB#0: derived from LLVM BB %entry > > 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, > > <ga:@val>[TF=5], %noreg; 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...

...1. Find an unused opcode, e.g. 0xF1 in this table: http://ref.x86asm.net/coder32.html 2. Insert an instruction into lib/Target/X86/X86InstrInfo.td using this opcode. In this case, I used 0xF1, and created the following instruction: def CACHE_OPERAND_B64i : RIi64<0xF1, AddRegFrm, (outs GR64:$unused), (ins i64imm:$b), "cache_operand_b_i64\t$b", [(int_cache_operand_b_i64 i64imm:$b)]>, Requires<[In64BitMode]>; However, when I compile, I'm getting errors of the form: Error: Primary decode conflict: TEST64ri32 would o...

...eudo AMX instruction is > generated. The name of pseudo instructions have ‘P’ prefix. Now all > the AMX pseudo instruction take vtile as register class. Let’s assume > %13 is constant 3, %10 is constant 4 and %14 is variable. > > /  %1:vtile = *P*TILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %2:vtile = *P*TILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %3:vtile = *P*TILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /%21:vtile = *P*TDPBSSDV %13:gr16, %10:gr16, %1...

...nside it): # Machine code for function main: SSA BB#0: derived from LLVM BB %entry ADJCALLSTACKDOWN64 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use> %vreg2<def> = MOV32ri64 <ga:@str>; GR32:%vreg2 %vreg3<def> = SUBREG_TO_REG 0, %vreg2<kill>, 4; GR64:%vreg3 GR32:%vreg2 %RDI<def> = COPY %vreg3; GR64:%vreg3 CALL64pcrel32 <ga:@puts>, <regmask>, %RSP<imp-use>, %RDI<imp-use>, %RSP<imp-def>, %EAX<imp-def> ADJCALLSTACKUP64 0, 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use> %vreg4&...

...SSA Frame Objects: fi#0: size=4, align=4, at location [SP+8] fi#1: size=4, align=4, at location [SP+8] fi#2: size=8, align=8, at location [SP+8] Function Live Ins: %EDI in %vreg0, %RSI in %vreg2 BB#0: derived from LLVM BB %entry Live Ins: %EDI %RSI %vreg2<def> = COPY %RSI; GR64:%vreg2 %vreg0<def> = COPY %EDI; GR32:%vreg0 %vreg1<def> = COPY %vreg0<kill>; GR32:%vreg1,%vreg0 %vreg3<def> = COPY %vreg2<kill>; GR64:%vreg3,%vreg2 %vreg5<def> = MOV64ri <ga:@.str>; GR64:%vreg5 MOV32mi <fi#0>, 1...

Currently, instruction selection patterns are defined like this: def : Pat<(and (not GR32:$src1), GR32:$src2), (ANDN32rr GR32:$src1, GR32:$src2)>; def : Pat<(and (not GR64:$src1), GR64:$src2), (ANDN64rr GR64:$src1, GR64:$src2)>; TableGen infers the types of $src1 and $src2 from the specified register classes, and that is the only purpose of the register classes in a pattern like that. SelectionDAG doesn't really understand register classes, it on...

...ruction is > generated. The name of pseudo instructions have ‘P’ prefix. Now > all the AMX pseudo instruction take vtile as register class. Let’s > assume %13 is constant 3, %10 is constant 4 and %14 is variable. > > /  %1:vtile = *P*TILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %2:vtile = *P*TILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %3:vtile = *P*TILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /%21:vtile = *P*TDPBSSDV %...

On Sep 1, 2010, at 11:14 AM, Dale Johannesen wrote: > > On Sep 1, 2010, at 6:25 AMPDT, Argyrios Kyrtzidis wrote: > >> The attached .ll files seem equivalent, but the resulting asm from >> 'opt-fail.ll' causes a crash to webkit. >> I suspect the usage of registers is wrong, can someone take a look ? > > Yes, the code here is wrong: > >> movl

...est/official.llvm/llvm/lib/Target/X86/X86InstrX86-64.td (revision 32608) +++ /usr/people/djg/svn/test/official.llvm/llvm/lib/Target/X86/X86InstrX86-64.td (revision 32609) @@ -1110,33 +1110,33 @@ // Move instructions... def MOV64toPQIrr : RPDI<0x6E, MRMSrcReg, (ops VR128:$dst, GR64:$src), - "movq {$src, $dst|$dst, $src}", + "mov{d|q} {$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector GR64:$src)))]>; def MOV64toPQIrm : RPDI<0x6E, MRMSrc...

...1:26:25 PM > Subject: [LLVMdev] Simpler types in TableGen isel patterns > > Currently, instruction selection patterns are defined like this: > > def : Pat<(and (not GR32:$src1), GR32:$src2), > (ANDN32rr GR32:$src1, GR32:$src2)>; > def : Pat<(and (not GR64:$src1), GR64:$src2), > (ANDN64rr GR64:$src1, GR64:$src2)>; > > TableGen infers the types of $src1 and $src2 from the specified > register classes, and that is the only purpose of the register > classes in a pattern like that. SelectionDAG doesn't really > unde...

...n selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as register class. Let's assume %13 is constant 3, %10 is constant 4 and %14 is variable. %1:vtile = PTILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %2:vtile = PTILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %3:vtile = PTILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %21:vtile = PTDPBSSDV %13:gr16, %10:gr16, %14:gr16, %3:vtile(tied-def 0), %1:vtile, %2:vtile 2. T...

...t we assign 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...