search for: codegenintrinsics

Hi, I need to generate a branch instruction from within CodeGenIntrinsic in SparcV9BurgISel.cpp. I generate a few instructions and add them to the mvec vector, and then I need to generate a branch whose target is the first instruction in the vector. I've seen how other portions of the code do this, but they have access to more information than CodeGenIntrinsic. Thanks, Brent

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

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

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > 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

Is there a reason that we don't have a definition for write-only intrinsics? Specifically, utils/TableGen/CodeGenIntrinsics.h contains: // Memory mod/ref behavior of this intrinsic. enum { NoMem, ReadArgMem, ReadMem, ReadWriteArgMem, ReadWriteMem } ModRef; The problem with this seems to be that "store" instructions, like the PPC STVX instruction, that are primarily defined by an intrinsic (...

Hi, What does it mean when "Commutative" property is applied to an intrinsic with more than two arguments? For example, __builtin_ia32_dppd has this property. Thanks. -- Simon

Is there a way to access the current MachineBasicBlock info from within CodeGenIntrinsic in SparcV9BurgISel.cpp? The arguments are: Intrinsic::ID iid, CallInst &callInstr, TargetMachine &target, and std::vector<MachineInstr*>& mvec, none of which seem to offer access to the current MachineBasicBlock. Brent

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pattern complexity = 8 cost

On Nov 30, 2011, at 1:54 PM, Hal Finkel wrote: > Is there a reason that we don't have a definition for write-only > intrinsics? Specifically, utils/TableGen/CodeGenIntrinsics.h contains: I don't think so, I'm not opposed to it. > If there is no particular reason for the current behavior, then I'll > propose a patch to add a WriteMem tag for intrinsics. Great, thanks! -Chris

Are you using isTarget = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1,

On 04/28/2012 04:30 PM, Justin Holewinski wrote: > We can handle this by provide a new argument (e.g. a string of > properly-configured Target Machine) instead of or in addition to the > Arch type string argument. > > > I think we may in general discuss the additional information needed > for the back ends and provide the information as

On Sat, Apr 28, 2012 at 3:16 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/28/2012 10:25 AM, Yabin Hu wrote: > >> Hi Justin, >> >> Thanks very much for your comments. >> >> 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com >> <mailto:justin.holewinski@**gmail.com <justin.holewinski at gmail.com>>> >>

At Thu, 15 Jul 2010 08:17:37 -0700, Peter Housel wrote: > The LLVM libraries provide the llvm::Intrinsic::getDeclaration() > function, which can provide a standard external declaration for any > of the (currently) 762 defined LLVM intrinsics, both for ordinary > intrinsics and for overrideable intrinsics with supplied parameter > types. Clients that do not link with the LLVM

The LLVM libraries provide the llvm::Intrinsic::getDeclaration() function, which can provide a standard external declaration for any of the (currently) 762 defined LLVM intrinsics, both for ordinary intrinsics and for overrideable intrinsics with supplied parameter types. Clients that do not link with the LLVM libraries (such as the Open Dylan compiler, which has its own IR and its own bitcode

On Sat, Apr 28, 2012 at 8:27 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/28/2012 04:30 PM, Justin Holewinski wrote: > >> We can handle this by provide a new argument (e.g. a string of >> properly-configured Target Machine) instead of or in addition to >> the >> Arch type string argument. >> >> >> I think we

On 04/28/2012 10:25 AM, Yabin Hu wrote: > Hi Justin, > > Thanks very much for your comments. > > 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com > <mailto:justin.holewinski at gmail.com>> > > On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com > <mailto:yabin.hwu at gmail.com>> wrote: > > The

Hi Justin, Thanks very much for your comments. 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com> > On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com> wrote: > >> The attached patch adds a new Intrinsic named "llvm.codegen" to support >> embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses >> the