search for: codegenintrinsic

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. T...

...t;getValueAsString("TypeVal") << ")"; + } +} + /// RecordListComparator - Provide a determinstic comparator for lists of /// records. namespace { @@ -176,6 +192,43 @@ OS << "#endif\n\n"; } +void IntrinsicEmitter::EmitGenerator(const std::vector<CodeGenIntrinsic> &Ints, + std::ostream &OS) { + OS << "// Code for generating Intrinsic function declarations.\n"; + OS << "#ifdef GET_INTRINSIC_GENERATOR\n"; + OS << " switch (ID) {\n"; + OS << " defau...

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

...t;getValueAsString("TypeVal") << ")"; + } +} + /// RecordListComparator - Provide a determinstic comparator for lists of /// records. namespace { @@ -176,6 +198,43 @@ OS << "#endif\n\n"; } +void IntrinsicEmitter::EmitGenerator(const std::vector<CodeGenIntrinsic> &Ints, + std::ostream &OS) { + OS << "// Code for generating Intrinsic function declarations.\n"; + OS << "#ifdef GET_INTRINSIC_GENERATOR\n"; + OS << " switch (id) {\n"; + OS << " defau...

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

...return Result; } } However, when MACRO_FMA is called, Tmp0->getZExtValue() returns 102! The section of code where this is probably wrong is: CodeGenDAGPatterns.cpp:1238 unsigned IID = getDAGPatterns().getIntrinsicID(Operator)+1; Or here: CodeGenDAGPatterns.h:524 const CodeGenIntrinsic &getIntrinsicInfo(unsigned IID) const { assert(IID-1 < Intrinsics.size() && "Bad intrinsic ID!"); return Intrinsics[IID-1]; } These are the only locations where I can find that it is returning the IID off by 1. If someone can let me know what I need...

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

...> > However, when MACRO_FMA is called, Tmp0->getZExtValue() returns 102! > > The section of code where this is probably wrong is: > CodeGenDAGPatterns.cpp:1238 unsigned IID = > getDAGPatterns().getIntrinsicID(Operator)+1; > Or here: > CodeGenDAGPatterns.h:524 > const CodeGenIntrinsic &getIntrinsicInfo(unsigned IID) const { > assert(IID-1 < Intrinsics.size() && "Bad intrinsic ID!"); > return Intrinsics[IID-1]; > } > > These are the only locations where I can find that it is returning > the IID off by 1. > > > If som...

...eneral > usefulness of this intrinsic. > > > Any solution would need to be able to handle Feature flags (e.g. > -mattr=+sm_20), as well as generic llc options (e.g. -regalloc=greedy). > What happens when the options conflict with the original options > passed to llc? The CodeGenIntrinsic pass would need to emulate all > (most?) of llc, but in a way that doesn't interfere with llc's global > state. Unfortunately, parameters like "regalloc=" are globals. To do > this without massive LLVM changes, you may need to spawn another > instance of llc as a sep...

...emand, in case we agreed on the general usefulness of this > intrinsic. Any solution would need to be able to handle Feature flags (e.g. -mattr=+sm_20), as well as generic llc options (e.g. -regalloc=greedy). What happens when the options conflict with the original options passed to llc? The CodeGenIntrinsic pass would need to emulate all (most?) of llc, but in a way that doesn't interfere with llc's global state. Unfortunately, parameters like "regalloc=" are globals. To do this without massive LLVM changes, you may need to spawn another instance of llc as a separate process. &gt...

...ackend (this would be number 28) in TableGen, making it that much harder to refactor and maintain. I'm not particularly worried about this, given that XMLIntrinsicEmitter uses the same interface to the rest of TableGen as the existing IntrinsicEmitter (namely the LoadIntrinsics function and the CodeGenIntrinsic class). An alternative, which would permit anyone to generate any information they need from TableGen would be to embed a Python interpreter, allowing users to execute arbitrary scripts. These scripts could traverse the TableGen data model and generate appropriate output; eventually all of the emi...

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

...ess of this intrinsic. >> >> >> Any solution would need to be able to handle Feature flags (e.g. >> -mattr=+sm_20), as well as generic llc options (e.g. -regalloc=greedy). >> What happens when the options conflict with the original options >> passed to llc? The CodeGenIntrinsic pass would need to emulate all >> (most?) of llc, but in a way that doesn't interfere with llc's global >> state. Unfortunately, parameters like "regalloc=" are globals. To do >> this without massive LLVM changes, you may need to spawn another >> instance...

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