similar to: [LLVMdev] GCCBuiltin and Intrinsic Mapping

On Sun, Sep 12, 2010 at 3:25 PM, David Greene <dag at cray.com> wrote: > I've run into an issue specifying intrinsics for AVX. > > Right now one can use GCCBuiltin to get automatic CBE (and other) > support for emitting intrinsics as gcc builtins.  It looks like > this: > >  def int_x86_sse3_hadd_pd : GCCBuiltin<"__builtin_ia32_haddpd">, >        

Eli Friedman <eli.friedman at gmail.com> writes: > int_x86_avx_vhadd_pd_xmm doesn't exist on trunk. Why does it exist on > your branch if the semantics are exactly equivalent to > int_x86_sse3_hadd_pd? The register allocator can handle converting to > three-address form if the target provides the appropriate hooks. Because in some cases users may want to explicitly use

On Mon, Sep 13, 2010 at 8:27 AM, David A. Greene <dag at cray.com> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> int_x86_avx_vhadd_pd_xmm doesn't exist on trunk.  Why does it exist on >> your branch if the semantics are exactly equivalent to >> int_x86_sse3_hadd_pd?  The register allocator can handle converting to >> three-address form

On Mon, Sep 13, 2010 at 8:27 AM, David A. Greene <dag at cray.com> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> int_x86_avx_vhadd_pd_xmm doesn't exist on trunk.  Why does it exist on >> your branch if the semantics are exactly equivalent to >> int_x86_sse3_hadd_pd?  The register allocator can handle converting to >> three-address form

I have a question about the SSE scalar convert intrinsics. cvtsd2si is defined thusly: def int_x86_sse2_cvtsd2si64 : GCCBuiltin<"__builtin_ia32_cvtsd2si64">, Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>; This matches the signature of the GCC intrinsic. The fact that the GCC intrinsic has a type mismatch on the input (vector rather than scalar) is

On Jun 5, 2009, at 8:51 AM, David Greene wrote: > I have a question about the SSE scalar convert intrinsics. > > cvtsd2si is defined thusly: > > def int_x86_sse2_cvtsd2si64 : > GCCBuiltin<"__builtin_ia32_cvtsd2si64">, > Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>; > > This matches the signature of the GCC intrinsic. The

On Mar 23, 2009, at 5:56 PM, David Greene wrote: > Is it legal to do something like a !strconcat on a non-string > entity? That > is, is there some operation that will let me do this (replace > SOME_CONCAT with > an appropriate operator): I don't get it, can you try a simpler example on me? :) -Chris > > > (WARNING! Hacked-up tablegen ahead!) > >

Is it legal to do something like a !strconcat on a non-string entity? That is, is there some operation that will let me do this (replace SOME_CONCAT with an appropriate operator): (WARNING! Hacked-up tablegen ahead!) multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr, SDNode OpNode> { // Vector operation emulating scalar (fp)

On Tuesday 24 March 2009 10:43, Chris Lattner wrote: > On Mar 23, 2009, at 5:56 PM, David Greene wrote: > > Is it legal to do something like a !strconcat on a non-string > > entity? That > > is, is there some operation that will let me do this (replace > > SOME_CONCAT with > > an appropriate operator): > > I don't get it, can you try a simpler example on

Hi, I was looking at the x86 vector intrinsics for converting half precision floating point numbers and I'm a bit confused as to why certain types were chosen. I've gone ahead and used their current definition with success but I'd like to understand why the types used with these intrinsics are done this way. For reference see ``include/llvm/IR/IntrinsicsX86.td``. Here are the

Hi Everyone！ I am a newbie at llvm. So the question may be fundamental but difficult to me. I want to add an trinsics in x86 and make the following changes.I want that max_qb can find the max of two Integers and return it. In src/include/llvm/IR/Intrinsics.td : let TargetPrefix = "x86" in { def int_x86_max_qb: GCCBuiltin<"__builtin_x86_max_qb">,

GCCBuiltin just gives it a name for clang to lookup. Generally they match up with builtins that gcc also implements, but that's not a requirement. If you add a builtin with the same name to the builtin file in clang's include/clang/Basic/Builtins*.def then they will find each other. You can also just add a builtin to clang's builtin file and catch it in clang's

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

I've created an intrinsic from my target, but I can't figure out how I can run it from a C code. Most of the targets have a GCCBuiltin and it looks like it is the way to execute an intrinsic from C code. However in my case there is no actual GCC built in. Any help on this is really appreciated. -- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part

Yeah. I agree that "Chain operand is needed if the intrinsic is reading / writing memory.”, Just don’t know where and how to set it up. like intrinsic “int_x86_xtest: “ def int_x86_xtest : GCCBuiltin<"__builtin_ia32_xtest">, Intrinsic<[llvm_i32_ty], [], []>; “ "def X86xtest: SDNode<"X86ISD::XTEST", SDTypeProfile<1, 0,

I want to generate Haskell bindings to LLVM intrinsics. In a first attempt I wrote a little parser that reads IntrinsicsX86.td and outputs a Haskell module. E.g. the definition def int_x86_avx_max_ps_256 : GCCBuiltin<"__builtin_ia32_maxps256">, Intrinsic<[llvm_v8f32_ty], [llvm_v8f32_ty, llvm_v8f32_ty], [IntrNoMem]>; is turned into

Hi，every one. This problem has been bothering me for several days.I really hope that you can help me. I want to add an trinsics in X86. This trinsics can compare two numbers and return the larger. There are the changes I do as fllowing. In /tools/clang/include/clang/Basic/BuiltinsX86.def : BUILTIN(__builtin_x86_max_qb, "iii", "") In include/llvm/IR/IntrinsicsX86.td : let

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

FYI, The CRC64 intrinsics were renamed to CRC32 since there is no such thing. See below for details. Chad On May 26, 2011, at 4:13 PM, Chad Rosier wrote: > Author: mcrosier > Date: Thu May 26 18:13:19 2011 > New Revision: 132163 > > URL: http://llvm.org/viewvc/llvm-project?rev=132163&view=rev > Log: > Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist.

Can anyone puzzle out what tblgen is trying to tell me here? VR256:v32i8:$src MD0.VMOVDQA_256mr: (st:isVoid VR256:v32i8:$src, addr:iPTR: $dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_alignedstore>> /ptmp/dag/universal_build/debug/DEFAULT/llvm/tblgen: In MD0.VMOVDQA_256mr: Type inference contradiction found in node! I don't see any