search for: numoperands

...;CallInst>(Insn)->getCalledValue();               const Function *LLVMIFunc= dyn_cast<Function>(LLVMIValue);                             if( LLVMIname.compare("llvm.dbg.declare") == 0 )                             {                               int x = 0;                 int numoperands = CI->getNumArgOperands();                 for( unsigned i = 0; i != numoperands; ++i)                 {                   Value *v = CI->getOperand(i);                   if( i == 1) //points to metadata for variable name                   {                     MDNode *mdnode = (MDNode *)CI-&...

...icBlock *BB) { assert(V && "PHI node got a null value!"); assert(BB && "PHI node got a null basic block!"); assert(getType() == V->getType() && "All operands to PHI node must be the same type as the PHI node!"); if (NumOperands == ReservedSpace) growOperands(); // Get more space! // Initialize some new operands. ++NumOperands; setIncomingValue(NumOperands - 1, V); setIncomingBlock(NumOperands - 1, BB); } -Filip On Nov 9, 2013, at 9:56 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wr...

...up/llvm-dev/browse_thread/thread/1a239f0d24db2b5c   http://markmail.org/message/fj5qg44vyjsdde7k#query:+page:1+mid:5zhmyncisenomcga+state:results           I could do following, to get the required information.                 const CallInst *CI = dyn_cast<CallInst>(Insn);                 int numoperands = CI->getNumArgOperands();                 for( unsigned i = 0; i != numoperands; ++i)                 {                   Value *v = CI->getOperand(i);                   MDNode *temp = (MDNode *)CI->getOperand(1) ;                   DIVariable DV(temp);//TO CHECK. remove later            ...

On 9 Nov 2013, at 16:35, William Moses <moses.williamsteven at gmail.com> wrote: > Is it possible to create something which has the same effect of a variable-length phi node in the C++ api. Specifically, create a phi-node where the number of incoming values is not known at the time of its creation. The PHI node preallocates its storage, so no. > If there is no such way of creating a

All, Is it possible to create something which has the same effect of a variable-length phi node in the C++ api. Specifically, create a phi-node where the number of incoming values is not known at the time of its creation. If there is no such way of creating a phinode like that, would it be possible to create a dummy instruction and perform a replaceAllUsesWith? If so, what should the dummy

...l action routine. One way to handle this might be to expand the use of SubclassData. There are 15 bits to play with and only the bottom 6-7 are in use (if I am reading it right). We can also reduce the width of following field NodeId (do we need 32-bit for it?) and widen SubclassData. Also, NumOperands and NumValues can be changed to take up fewer bits. I don't think we need 16-bits for each. So NodeType, OperandsNeedDelete, SubclassData, NodeId, NumOperands, and NumValues together are using 96 bits (assuming int is 32-bit and short is 16-bit). I think there is opportunity here to re-p...

...the number of operands of the instruction? This should influence the >> number of extracts needed, so instead of >> >> Scalarization cost = NumEls * (insert + extract) >> >> it would be better to do >> >> Scalarization cost = NumEls * (insert + (extract * numOperands)) > > I suspect this is an oversight (although we need to be a bit careful > here because if two operands are the same, which is not uncommon, we > don't want to double the cost). > > -Hal Do you in those cases of an identical operand want to count just a cost of "1&...

...duce the width of following > field NodeId (do we need 32-bit for it?) and widen SubclassData. Yep. See my response to Dan. I don't know how many target-specific flags you need, but we should be able to carve out four more bits from SubclassData without changing anything else. > Also, NumOperands and NumValues can be changed to take up fewer bits. > I don't think we need 16-bits for each. Probably true. > So NodeType, OperandsNeedDelete, SubclassData, NodeId, NumOperands, > and NumValues together are using 96 bits (assuming int is 32-bit and > short is 16-bit). I think the...

...r why getScalarizationOverhead() does not take into account the number of operands of the instruction? This should influence the number of extracts needed, so instead of Scalarization cost = NumEls * (insert + extract) it would be better to do Scalarization cost = NumEls * (insert + (extract * numOperands)) / Jonas

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode

...ounds access: ~> llc bug-simple.bc llc: /local/martind/oss/llvm-3.5.0.src/include/llvm/CodeGen/SelectionDAGNodes.h:649: llvm::EVT llvm::SDNode::getValueType(unsigned int) const: Assertion `ResNo < NumValues && "Illegal result number!"' failed. Probably the truncation of NumOperands should be caught directly with an assertion in the SDNode constructor. One other interesting aspect of it is that if you make the struct_2 type a smaller matrix, like: %struct_2 = type { [65534 x %struct_1] } Then you don't get a crash, instead it takes about 20+ minutes to process and you ge...

...t;llvm::Value> = { _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = 0x61035c0, UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 'D', HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', SubclassData = 0, NumOperands = 3, static MaximumAlignment = 536870912}, OperandList = 0x61b8e80} (gdb)

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

...reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile - This profile describes the type requirements of a Selection // DAG node. class SDTypeProfile<int numresults, int numoperands, list<SDTypeConstraint> constraints> { int NumResults = numresults; int NumOperands = numoperands; list<SDTypeConstraint> Constraints = constraints; } // So: 2 results, 3 operands. // Params a...

...)[Idx]; + } + template <unsigned Idx> const Use &Op() const { + return OperandTraits<User>::op_begin(const_cast<User*>(this))[Idx]; + } + Use *allocHungoffUses(unsigned) const; + void dropHungoffUses(Use *U) { + if (OperandList == U) { + OperandList = 0; + NumOperands = 0; + } + Use::zap(U, U->getImpliedUser(), true); + } At a very brief scan, it looks like allocHungoffUses and dropHungoffUses can be made protected, not public. And maybe those Op things too. Hmm, and why the operand index for Op is a non-type template parameter? In an optimized build...

...0x60c67f0 <vtable for llvm::CallInst+16>, VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, > SubclassID = 68 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.ui...

...into a pointer to begin with, but surely the lower bits must be a safer location than the upper bits? The actual crash I'm seeing is preceded by an assert in X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing backward, I'm seeing a MachineInstr with opcode MOV32rm and NumOperands equal to 6 (which is 5 in earlier revisions). I'm not sure if this actually helps explain the bug but it's one of the weird things that happen with revision 67979 and subsequent revisions. All help appreciated. Nicolas -------------- next part -------------- An HTML attachment was...

...t; _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 > 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev &...

...; to follow, error: "Assertion `New->getNumTypes() == 1"). > > masked_gather returns 2 values because: > // SDTypeProfile - This profile describes the type requirements of a Selection > // DAG node. > class SDTypeProfile<int numresults, int numoperands, > list<SDTypeConstraint> constraints> { > int NumResults = numresults; > int NumOperands = numoperands; > list<SDTypeConstraint> Constraints = constraints; > } > > // So: 2 results, 3 oper...