similar to: Why is llvm.maxnum.f32 coming through unreduced?

On 11/15/2015 01:29 PM, Tim Northover wrote: > On 15 November 2015 at 09:01, Rodney M. Bates via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> The latter is reduced to machine code by llc, the former is not, instead >> coming through as an external function call, which then fails to link. > > Is this for x86? I don't think that has a single instruction to >

Hi, The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize). Currently according to the LangRef: Follows the IEEE-754 semantics for minNum, which also

> On Jul 23, 2018, at 3:40 PM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 23 July 2018 at 11:56, Arsenault, Matthew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> Hi, >> >> >> The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear >> right

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,

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

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

On Sep 15, 2014, at 4:17 PM, Owen Anderson <resistor at mac.com> wrote: > I’d be fine with that proposal. I could even be convinced if we wanted to add a pair of NaN-propagating intrinsics as well, for targets and languages that want those semantics, even if I disagree with them. I do think that, if we are using the minnum/maxnum names, we should explicitly note that they are

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:

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[] =

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());

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

I am, from a front end, calling functions like LLVMModuleCreateWithName, found in Core.h, ultimately calling LLVMWriteBitcodeToFile, found in BitWriter.h. Do I correctly presume, from the existence of LLVMDisposeModule, that I am responsible for calling it when I'm done? Will I need to do deeper disposing myself? I presume at least I will need to free strings I allocated myself, such as the

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 =

Before metadata was separated from values, I could create a debug info forward declaration and eventually resolve it using LLVMReplaceAllUsesWith in core.h. Now, I can't figure out how to resolve it. I can find no function that seems to do this. My one wild guess that giving the forward decl and the resolving decl the same UniqueId might do it is not working. I am currently using 3.6.1, but

I am generating llvm code for nested procedures. Each one gets a static link, which I am passing as an internally added, first parameter. However, it needs to be stored in memory too, so a debugger can find it. So, when I need to use the value, is it better to use the ssl parameter or load the memory copy? I can imagine the ssl value might avoid unnecessary fetches, but then, it might also

According to the Assembly language reference: "In LLVM, opaque types can eventually be resolved to any type (not just a structure type)." But the only way I can think of to do so is to give it a type name, then later redeclare the name. But that gives an error: %TO = type opaque %TF = type i32 ( %TO* ) %TO = type %TF gives: $ llvm-as types1.ll llvm-as: types1.ll:3:1: error:

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

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.

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 :

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,