similar to: [LLVMdev] x86 SSE4.2 CRC32 intrinsics renamed

Hi, I'm trying to use the SSE4.2's instruction _mm_crc32_u64 and also added -msse4.2 flag in the makefile, but yet I get this error when I try to compile my code with clang/llvm. LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse42.crc32.64.64 I also tried to pass -march=native, but still no luck. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, May 3, 2013 at 11:07 AM, Blind Faith <person.of.book at gmail.com>wrote: ... > "You may be passing operands of the wrong type to the intrinsic" -> Well > I don't do anything to the LLVM bit code, I just try to compile my C code, > all code being generated by clang. > Sorry for misunderstanding... I have a simple test here that generates

Hello! Can someone please tell me if is there an API (or some other way) to query MCInstrDesc to find out the type of its memory operands? As an example, consider the following description of MOV32mr (from X86InstrInfo.td) def MOV32mr : I<0x89, MRMDestMem, (outs), (ins i32mem:$dst, GR32:$src), "mov{l}\t{$src, $dst|$dst, $src}", [(store GR32:$src,

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

On Thu, Mar 21, 2013 at 2:26 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > 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)>; > >

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu > Sent: Thursday, March 21, 2013 1:26:25 PM > Subject: [LLVMdev] Simpler types in TableGen isel patterns > > Currently, instruction selection patterns are defined like this: >

This sounds great! I've been bitten in the past by trying to use a single class for multiple types. Would it make sense to extend this to all DAG patterns? If I have an instruction def: def ANDN64 : MyInst<(outs Reg64:$d), (ins Reg64:$a, Reg64:$b), "and.64 $d, $a, $b", [(set Reg64:$d, (and (not (Reg64:$a, Reg64:$b))))]>; would I now be able to write: def ANDN64 :

Tracking down a problem with one of our benchmark codes, we've discovered that some of the patterns in X86InstrX86-64.td are wrong. Specifically: def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins i64mem:$src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector

Hey Jakob, On Thu, Mar 21, 2013 at 2:26 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > 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)>;

Hi, Thx for your help... Here is the IR code: ; ModuleID = 'foo_bar.c' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @.str = private unnamed_addr constant [6 x i8] c"MAIN\0A\00", align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** %argv) #0 { entry: %retval = alloca i32,

Consider this program: --- asm.c --- int G; int foo(char *p) { int rv; G = 0; asm ("" : "=r"(rv) : "r"(p) : "memory"); return rv + G; } ------------- Is the use of "memory" clobber sufficient to expect the optimizer not to optimize the "+ G" away in the return statement? I'll add here that

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

Some time ago I saw a report of strange single-stepping behavior given Swift code that looks like this: 1| var input = [16, 14, 10, 9, 8, 7, 4, 3, 2, 1] //< Only number 1 is relevant. 2| print("start") TL;DR: The debugger steps from line 2 -> 1 -> 2 in this code example. One clean way to fix this bug is to remove debug locations from ConstantSDNodes, and I'm asking if

Hello, I did as you said, Please tell me whether the following correct now?? def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, _.KRCWM:$mask_wb), (VR_2048:$src1, _.KRCWM:$mask, ins i2048mem:$src2), "GATHER_256B\t{$src2, {$dst}{${mask}}|${dst} {${mask}}, $src2}"), [(set VR_2048:$dst, _.KRCWM:$mask_wb, (v64i32 (GatherNode

i want to implement gather for v64i32. i wrote following code. def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst), (ins i2048mem:$src), "GATHER_256B\t{$src, $dst|$dst, $src}", [(set VR_2048:$dst, (v64i32 (masked_gather addr:$src)))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (masked_gather addr:$src)), (GATHER_256B

Hello LLVMer's I am now trying to fix a bug PR9473. sitofp instruction in LLVM IR is converted to vcvtsi2sd(also applied to vcvtsi2ss case) for x86/AVX backend, but vcvtsi2sd is somewhat odd instruction format. VCVTSI2SD xmm1, xmm2, r/m32 VCVTSI2SD xmm1, xmm2, r/m64 bits(127:64) of xmm2 is copied to corresponding bits of xmm1, thus in many case xmm1 and xmm2 could be same register.

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> If the 128-bit register is not ever used as a 128-bit register, >> shouldn't the coalescer pick the 64- or 32-bit register? > > That optimization is not currently implemented for sub-registers. For > example, if you create a GR64 virtual register and only ever use the > sub_32bit sub-register, it would be

On Jul 26, 2012, at 10:28 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >>> What happens if the result of the above pattern using COPY_TO_REGCLASS >>> is spilled? Will we get a 64-bit store or a 128-bit store? >> >> This behavior isn't affected by the change. FR64 registers are spilled >> with 64-bit

Thank You. Still getting errors.I have modified my instructions as you said as follows: def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, VK64WM:$mask_wb), (ins VR_2048:$src1, VK64WM:$mask, i2048mem:$src2), "GATHER_256B\t{$src2, {$dst} {${mask}}|${dst} {${mask}}, $src2}", [(set VR_2048:$dst, VK64WM:$mask_wb, (v64i32 (masked_gather