similar to: [LLVMdev] Question: overloaded intrinsic

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Question: overloaded intrinsic"

2007 Apr 20
0
[LLVMdev] llvm-gcc Bug, Looking for Advice on Fix
David Greene wrote: > The problem is that Intrinsic::getDeclaration takes four > parameters but is only passed two: > > Function *Intrinsic::getDeclaration(Module *M, ID id, const Type **Tys, > unsigned numTys) It turns out that this happens all over llvm-convert.c. Tys and numTys default to zero, which is why it builds. The problem is,
2007 Apr 20
2
[LLVMdev] llvm-gcc Bug, Looking for Advice on Fix
Ok, I've tracked down the problem I've had bootstrapping llvm-gcc. The culprit is in TreeToLLVM::EmitMemCpy: void TreeToLLVM::EmitMemCpy(Value *DestPtr, Value *SrcPtr, Value *Size, unsigned Align) { const Type *SBP = PointerType::get(Type::Int8Ty); const Type *IntPtr = TD.getIntPtrType(); Value *Ops[4] = { CastToType(Instruction::BitCast,
2015 Jan 15
2
[LLVMdev] Overloaded intrinsics: name explosion
Hi, So, we currently have gc.result.int, gc.result.float. gc.result.ptr, gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with a iPTRAny as the first argument. gc.result is in trouble, because none of the signatures admit even a simple array of integers, and there's no aAny. And certainly no vectors. So we can get a gc.result.vector to add to this mess, and admit [1] to
2008 Feb 20
1
[LLVMdev] Invalid intrinsic name error
Hi, Thank You for the advice and we were able to solve that problem by the following modifications to the Instrinsics.td file. But I now have an "Invalid Intrinsic name" error This error occurs presumably because the created intrinsic is named: llvm.migrate_begin.i32 Intrinsics.gen checks for a string length of 18 (i.e. the length without the .i32). Kindly help me through it.
2009 May 15
1
[LLVMdev] Intrinsic
Hi, I'm trying to use exception control by LLVM. In the demo page, I got : declare i8* @llvm.eh.exception() nounwind But, when a try to emit the code by llvm engine, the name is generate with the sufix .132 ( llvm.eh.exception.132 ) and the Function::getIntrinsicID abort the program. It was so : Intrinsic::getDeclaration(llvm_module,Intrinsic::memset,&Tys,1); Now, it's
2016 Jul 22
2
HEAD compilation causes gcc internal error
After worked around the problem in SimplifyCFG.cpp (calling isCast() instead of comparing opcode), I hit another gcc crash for FunctionImport.cpp line 480, which I have no idea what's wrong with the code. "Luckily", I found gcc4.8.2 and gave it a try, both crashes are gone. *New problem though:* /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp: In member function
2009 Mar 24
2
[LLVMdev] Reducing .td redundancy
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
2006 Nov 15
1
[LLVMdev] LowerCALL (TargetLowering)
Hi Evan, On Wed, Nov 15, 2006 at 10:17 -0800, Evan Cheng wrote: > Hi Nickhil, > > The Legalizer expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it
2006 Nov 15
0
[LLVMdev] LowerCALL (TargetLowering)
Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at
2013 Oct 10
3
[LLVMdev] A new builtin: __builtin_stack_pointer()
One of the issues the LLVMLinux project is having is with the use of named registers in the Linux kernel code. The kernel uses something like this in order to assign a C variable name to a register (one for each kernel arch). register unsigned long current_stack_pointer asm("esp"); clang doesn't allow this kind of thing which required a patch which less efficient: #define
2006 Nov 15
2
[LLVMdev] LowerCALL (TargetLowering)
Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:
2009 Sep 07
0
[LLVMdev] PR4882
Hi Jakub, looks good. > + LLVMContext *Context = &SI->getContext(); I guess this could be LLVMContext &Context = SI->getContext(); which means you can use Context rather than *Context below. > - const Type *Ty = Type::getInt64Ty(SI->getContext()); > - MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset, &Ty, 1); > + const Type *Tys[] =
2009 Sep 07
1
[LLVMdev] PR4882
On Sep 7, 2009, at 5:02 PM, Duncan Sands wrote: > Hi Jakub, looks good. > >> + LLVMContext *Context = &SI->getContext(); > > I guess this could be > LLVMContext &Context = SI->getContext(); > which means you can use Context rather than *Context below. Right, C bad habit ;) Fixed. >> - const Type *Ty = Type::getInt64Ty(SI->getContext());
2012 Jul 04
0
[LLVMdev] Bogus assert in VMCore/Instructions.cpp CallInst::Create?
Andrew Ruef wrote: > Evening, > > I was writing some code that tried to insert calls to the > llvm.annotation intrinsic function, which has a signature of (i32, > i8*, i8*, i32). The code is below. > > void addAnnotation( BasicBlock *block, Function *F) > { > string foo = "foo"; > string bar = "barr"; > > Type
2012 Jul 04
2
[LLVMdev] Bogus assert in VMCore/Instructions.cpp CallInst::Create?
Evening, I was writing some code that tried to insert calls to the llvm.annotation intrinsic function, which has a signature of (i32, i8*, i8*, i32). The code is below. void addAnnotation( BasicBlock *block, Function *F) { string foo = "foo"; string bar = "barr"; Type *charTy = Type::getInt8Ty(block->getContext()); ArrayType *s1Ty =
2017 Jul 25
2
How to migrate x86_sse2_psrl_dq after LLVM v3.8?
Hi LLVM developers, After Remove int_x86_sse2_psll_dq_bs and int_x86_sse2_psrl_dq_bs intrinsics. The builtins aren't used by clang. https://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F,
2008 Feb 19
2
[LLVMdev] Problem with variable argument intrinsics
Hi, I tried creating variable argument intrinsics which are to be placeholders for some instructions which should not be executed by the backend. Kindly help me with the errors in my "migrate_begin" intrinsic creation //Additions made to Intrinsics.td file: def llvm_migrate_begin : LLVMType<iAny>; def int_migrate_begin :
2008 Feb 12
0
[LLVMdev] Inrinsic Creation Problem
Hi, I tried creating intrinsics which are to be placeholders for some instructions which should not be executed by the backend. Kindly help me with the errors in my "migrate_begin" intrinsic creation The following are the additions made to the Intrinsics.td file def llvm_migrate_begin : LLVMType<iAny>; def int_migrate_begin : Intrinsic<[llvm_migrate_begin,llvm_vararg_ty],
2009 Mar 24
0
[LLVMdev] va_start
Hi, When I try to use va_start(ptr), I got the following problem : Type *Tys = Type::VoidTy; Or Type *Tys = PointerType::get(IntegerType::get(8), 0); return Intrinsic::getDeclaration(llvm_module,Intrinsic::vastart,&Tys,1); ............... The Name generated is "llvm.va_start.p0i8", so, it's not found, abending the process. and Len = 18 In intrinsics.gen : if (Len == 13
2017 Jul 11
2
Using new types v32f32, v32f64 in llvm backend not possible
Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in