search for: iani

Hi, I've been hitting my head to wall two 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], [],

The ARM Neon load, store and shuffle operations that I've been implementing recently with LLVM intrinsics do not care about the distinction between vectors with i32 and f32 elements -- only the size matters. But, because we have only MVT::fAny and MVT::iAny types, I've been having to define separate intrinsics for the operations with floating-point vector elements. 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 :

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

On Feb 19, 2008, at 1:11 AM, aditya vishnubhotla wrote: > 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

Hi Manuel, Here's another commit authored through the web interface where no discussion or reviewership information is apparent on the mailing list. All we see in cases like this are a few unthreaded list posts by the original author followed by an SVN revision number: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140714/226166.html For any patch that's submitted for

Hi Bob, An alternative would be to model the operations as regular shuffle, load, and store operators, combined to describe the actual instructions. This would make them easier for target-independent code to understand. Dan On Aug 8, 2009, at 11:47 PM, Bob Wilson <bob.wilson at apple.com> wrote: > The ARM Neon load, store and shuffle operations that I've been >

On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote: > I really do think that bitcast is the right way to go here. I ran > into a couple of similar problems when bringing up the altivec port. > For example, at one time we'd get "all zero vectors" of different > MVTs, which would not be CSEd. > > The fix for this was to be really disciplined about what types to make

On Aug 8, 2009, at 11:47 PM, Bob Wilson wrote: > The ARM Neon load, store and shuffle operations that I've been > implementing recently with LLVM intrinsics do not care about the > distinction between vectors with i32 and f32 elements -- only the size > matters. But, because we have only MVT::fAny and MVT::iAny types, > I've been having to define separate intrinsics for

On 17/07/2014 20:27, Eric Christopher wrote: > Hi Alp, > > On Thu, Jul 17, 2014 at 6:25 AM, Alp Toker <alp at nuanti.com> wrote: >> Hi Manuel, >> >> Here's another commit authored through the web interface where no discussion >> or reviewership information is apparent on the mailing list. > If you look at the phab review, it's the same there. Does

Hello All, I have been modifying LLVM a project of mine, and have encountered issues with overloading an intrinsic function. I have defined two types, abit (which is mapped, in Intrinsics.td, to i128) and qbit (accordingly mapped to i16). I would like my intrinsic function, CNOT(x,y), to accept either an abit or a qbit for each argument, so I overload with iAny and llvm_anyint_ty, as seemed to

<table cellspacing='0' cellpadding='0' border='0' ><tr><td style='font: inherit;'>Hi,<br>I tried creating intrinsics which are to be<br>placeholders for a set of instructions (actually a section of a basic block) to be executed elsewhere(for e.g. in HW).<br>These intrinsics are to take care of the data dependencies of the set of

Hi. I am beginning to learn LLVM (using LLVM 2.3.0 on a Linux x86_64 machine) and wanted to check the status of the support of arbitrary size integers. To do so, I tried to modify the HowToUseJIT example by replacing the Int32Ty with another size (let's say 12 bits for the example). While it compiles ok, I get the following assert at run-time: HowToUseJIT: LegalizeDAG.cpp:4059:

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 David, The error shows that the clang source code uses this intrinsic as well, but in the old form. You need to modify the clang source code (where this intrinsic is used) to consider the overloaded operands. The assert would show the trace where clang uses this intrinsic. Hope this helps, Anna > On Jul 26, 2016, at 3:21 PM, David Noursi via llvm-dev <llvm-dev at lists.llvm.org>

Hello, LLVM's intrinsic overloading mechanism does not currently support overloading on pointer types. Patches to implement this would be welcome. Dan On May 7, 2008, at 9:25 AM, aditya vishnubhotla wrote: > Hi, > I tried creating intrinsics which are to be > placeholders for a set of instructions (actually a section of a > basic block) to be executed elsewhere(for e.g. in

On Aug 9, 2009, at 6:29 AM, Dan Gohman wrote: > Hi Bob, > > An alternative would be to model the operations as regular shuffle, > load, and store operators, combined to describe the actual > instructions. This would make them easier for target-independent code > to understand. Yes, I have tried to do that as much as possible. There are still a number of operations where

On Mon, Jun 11, 2007 at 03:39:40PM -0700, Chris Lattner wrote: > On Mon, 11 Jun 2007, Dan Gohman wrote: > > Also, CopyToReg and CopyFromReg lowering/legalization rely on being able to > > create vector-of-vector types. For example, an <8 x double> vector is bitcasted > > to (effectively) <4 x <2 x double>> for x86, allowing EXTRACT_ELEMENT to pull > >

Hello, I've observed in some tests that getValueTypeList() is sometimes called with type MVT::iPTR. There is a discrepancy between the size of the array VTs and the use in getTypeValueList(). The array is allocated with space for elements up to LAST_VALUE_TYPE and iPTR is defined after it. The enumerator value of iPTR is between LAST_VALUE_TYPE and LastSimpleValueType. For this reason the

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],