search for: llvm_void_ty

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

...llvm/Intrinsics.td @@ -68,6 +68,15 @@ LLVMType ElTy = elty; } +class LLVMPointerType<LLVMType elty> + : LLVMType<iPTR, "Type::PointerTyID">{ + LLVMType ElTy = elty; +} + +class LLVMEmptyStructType + : LLVMType<OtherVT, "Type::StructTyID">{ +} + def llvm_void_ty : LLVMType<isVoid, "Type::VoidTyID">; def llvm_bool_ty : LLVMIntegerType<i1, 1>; def llvm_i8_ty : LLVMIntegerType<i8 , 8>; @@ -76,9 +85,10 @@ def llvm_i64_ty : LLVMIntegerType<i64, 64>; def llvm_float_ty : LLVMType<f32, "...

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

...t; Index: include/llvm/IntrinsicsPowerPC.td > =================================================================== > --- include/llvm/IntrinsicsPowerPC.td (revision 54985) > +++ include/llvm/IntrinsicsPowerPC.td (working copy) > @@ -26,6 +26,9 @@ > def int_ppc_dcbtst: Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; > def int_ppc_dcbz : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; > def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; > + > + // sync instruction > + def int_ppc_sync : Intrinsic<[llvm_voi...

...-- next part -------------- Index: include/llvm/IntrinsicsPowerPC.td =================================================================== --- include/llvm/IntrinsicsPowerPC.td (revision 54985) +++ include/llvm/IntrinsicsPowerPC.td (working copy) @@ -26,6 +26,9 @@ def int_ppc_dcbtst: Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; def int_ppc_dcbz : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; + + // sync instruction + def int_ppc_sync : Intrinsic<[llvm_void_ty], [IntrWriteMem]>...

...-- next part -------------- Index: include/llvm/IntrinsicsPowerPC.td =================================================================== --- include/llvm/IntrinsicsPowerPC.td (revision 54985) +++ include/llvm/IntrinsicsPowerPC.td (working copy) @@ -26,6 +26,9 @@ def int_ppc_dcbtst: Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; def int_ppc_dcbz : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; + + // sync instruction + def int_ppc_sync : Intrinsic<[llvm_void_ty], [IntrWriteMem]>...

...lvm/IntrinsicsPowerPC.td >> =================================================================== >> --- include/llvm/IntrinsicsPowerPC.td (revision 54985) >> +++ include/llvm/IntrinsicsPowerPC.td (working copy) >> @@ -26,6 +26,9 @@ >> def int_ppc_dcbtst: Intrinsic<[llvm_void_ty, llvm_ptr_ty], >> [IntrWriteMem]>; >> def int_ppc_dcbz : Intrinsic<[llvm_void_ty, llvm_ptr_ty], >> [IntrWriteMem]>; >> def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], >> [IntrWriteMem]>; >> + >> + // sync instruction &g...

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

...ave direct support for this in tblgen, for example, include/llvm/IntrinsicsX86.td contains: let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.". def int_x86_sse_movnt_ps : GCCBuiltin<"__builtin_ia32_movntps">, Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_v4f32_ty], [IntrWriteMem]>; } and lib/Target/X86/X86InstrSSE.td contains: def MOVNTPSmr : PSI<0x2B, MRMDestMem, (outs), (ins i128mem:$dst, VR128:$src), "movntps {$src, $dst|$dst, $src}", [(int_x...

Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI<bits<6> op, dag outs, dag ins, string asmstr, list<dag> pattern, InstrItinClass itin>: FI<op, outs, ins, asmstr, pattern, itin> { let isBarrier = 1; // or call, hassideefects, ..., no...

...o days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [], "llvm.tce.customop">; I made opt pass that converts __custom_op() functions to calls to llvm.tce.customop calls. shell> grep llvm.tce.customop hello2.ll tail call void (i8*, ...)* @llvm.tce.customop( i8* getelementptr ([7 x i8]* @.str,...

Hi, I was talking with aKor in #llvm how we could implement custom operation support for our ASIP architecture. We came into solution that the best way would be to write new custom operation intrinsic and optimization pass for raising certain type of function calls to those intrinsics (similar to raising mallocs). Basically our custom operation are like calls, with operand name and multiple

Hello, Julio > These later things are ignored, I don't know if when the intrinsic is > lowered, then it doesn't matter (or perhaps the reorder is made > before). What is the description of the instruction you're lowering intrinsic into? Have you looked for the instruction flags defined in Target.td file? You instruction should definitely have "isBarrier" flag set.

Hi: I want add new Instrinsic for my target. So I first do some test. I add them in IntrinsicsPowerPC.td //===--------------------===// let TargetPrefix = "ppc" in { def int_ppc_mytest : Intrinsic<[llvm_void_ty], [], [IntrWriteMem]>; } //===--------------------===// I add them in PPCInstrInfo.td //===--------------------===// def MYTEST : XForm_24_sync<31, 599, (outs), (ins),                         "mytest", LdStSync,                         [(int_ppc_mytest)]>; //===----------------...

..."sel\t%o.ww.$outline=%i.ww.$inport", [(int_my_su_route imm:$inport, imm:$outline)]>; My intrinsic function is defined this way in the .td file that describes my target intrinsics: def int_my_su_route : Intrinsic<[llvm_void_ty], [llvm_i8_ty, llvm_i8_ty], [IntrNoMem]>; This int_my_su_route function is of "void" type and it should take two byte-size immediate arguments. Can anyone point me to my error? Thanks a lot. -- Fima

Bill, > The built-in dwarf_cfa doesn't take an argument. It returns a pointer. Ah. Sorry for confusion: gcc's __builtin_draft_cfa doesn't have any argument LLVM's eh_dwarf_cfa intrinsic has extra "offset" argument, which is i32, because we have to propagate some information from GCC to LLVM. > But there's an offset associated with the CFA. So it looks like

Hello, I have an intrinsic that matches to a asm instruction directly. This intrinsic starts a coprocessor that can do anything. If I put another instruction next to it (a multiplication for example), the "llc" reorders and puts the intrinsic after the multiplication. I have tried all: - Setting the instruction like if it takes 256 cycles or 0 cycles. - Setting the instruction with

On Jan 6, 2010, at 1:12 PM, fima rabin wrote: > I am trying to compile a little intrinsic function for my machine. Here is a dump from clang-cc with --emit-llvm option: > ===================== > > ; ModuleID = 'foo.c' > target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" >

...irect support for this in > tblgen, for example, include/llvm/IntrinsicsX86.td contains: > > let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.". > def int_x86_sse_movnt_ps : GCCBuiltin<"__builtin_ia32_movntps">, > Intrinsic<[llvm_void_ty, llvm_ptr_ty, > llvm_v4f32_ty], [IntrWriteMem]>; > } > > and lib/Target/X86/X86InstrSSE.td contains: > > def MOVNTPSmr : PSI<0x2B, MRMDestMem, (outs), (ins i128mem:$dst, > VR128:$src), > "movntps {$src, $dst|$dst, $src}", > [(int_x86_sse_movnt_ps addr:$ds...