search for: extractelementinst

...re i32 %extract4, i32* %46, align 4 The output of my program is different that the expected one, like the extractelement takes an undefined value. The instructions I used are: Instruction *Insert0 = InsertElementInst::Create(vector, Or_set, index0, "ins or"); .. Instruction *extract = ExtractElementInst::Create(vector, ch, "extract"); //where ch takes a value from 0 to 2 instr->replaceAllUsesWith(extract); //where I want to replace the instr instruction with the instruction from the vector. I am new in the LLVM and I am not sure if I have done something wrong. Any suggestions are...

...::CreateExtractElement(llvm::Constant*, llvm::Constant*) const’: /work/llvm/include/llvm/User.h:48: error: ‘static void* llvm::User::operator new(size_t)’ is private /work/llvm/include/llvm/Support/NoFolder.h:177: error: within this context /work/llvm/include/llvm/Instructions.h:1177: error: ‘llvm::ExtractElementInst::ExtractElementInst(llvm::Value*, llvm::Value*, const llvm::Twine&, llvm::Instruction*)’ is private /work/llvm/include/llvm/Support/NoFolder.h:177: error: within this context Patch attached Artur -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

...uot;vSelect3",funcType)); BasicBlock* basicBlock = new BasicBlock("body",func); Function::arg_iterator args = func->arg_begin(); Argument* x = args; x->setName("x"); Value* v1 = makeVector(x,4,basicBlock); Value* s = new ExtractElementInst(v1,3,"s",basicBlock); new ReturnInst(s,basicBlock); return func; } // modified from the fibonacci example int main(int argc, char **argv) { Module* pVectorModule = new Module("test vectors"); Function* pMain = generateVectorAndSelect(pVectorM...

...// candidate chains where longer chains are considered to be better. > + // Note: when this function returns 0, the resulting instructions are > + // not actually fused. > + static inline size_t getDepthFactor(Value *V) { > + if (isa<InsertElementInst>(V) || isa<ExtractElementInst>(V)) { Why have InsertElementInst, ExtractElementInst instructions a weight of zero? > + return 0; > + } No need for braces. > + > + return 1; > + } > + > + // This determines the relative offset of two loads or stores, returning > + // true i...

...s where longer chains are considered to be better. > > + // Note: when this function returns 0, the resulting instructions are > > + // not actually fused. > > + static inline size_t getDepthFactor(Value *V) { > > + if (isa<InsertElementInst>(V) || isa<ExtractElementInst>(V)) { > > Why have InsertElementInst, ExtractElementInst instructions a weight of > zero? Two reasons: First, they cannot be usefully fused. Second, because the pass generates a lot of these, they can confuse the simple metric used to compare the trees in the next iteration. Thus, gi...

...er chains are considered to be better. >>> + // Note: when this function returns 0, the resulting instructions are >>> + // not actually fused. >>> + static inline size_t getDepthFactor(Value *V) { >>> + if (isa<InsertElementInst>(V) || isa<ExtractElementInst>(V)) { >> >> Why have InsertElementInst, ExtractElementInst instructions a weight of >> zero? > > Two reasons: First, they cannot be usefully fused. Second, because the > pass generates a lot of these, they can confuse the simple metric used > to compare the trees i...

...s where longer chains are considered to be better. > > + // Note: when this function returns 0, the resulting instructions are > > + // not actually fused. > > + static inline size_t getDepthFactor(Value *V) { > > + if (isa<InsertElementInst>(V) || isa<ExtractElementInst>(V)) { > > Why have InsertElementInst, ExtractElementInst instructions a weight of > zero? > > > + return 0; > > + } > No need for braces. > > > + > > + return 1; > > + } > > + > > + // This determines the rela...

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

...Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, dword ptr [eps] cause grief. My AllocaInstr instructions are told to be 16 byte aligned, so the addition of a 4-byte parameter shouldn't have changed alignment on the objects. The unpcklps instruction is coming from an ExtractElementInst or InsertElementInst. I can always hard code these by cyling my vectors to memory and doing things one scalar at a time, though perf will suffer. I'll try it Monday to see if it gets rid of the alignment sensitive instructions. I'm noticing this under windows via JIT. I'm going to...

...cBlock = new BasicBlock("body",func); > > > > Function::arg_iterator args = func->arg_begin(); > > Argument* x = args; > > x->setName("x"); > > > > Value* v1 = makeVector(x,4,basicBlock); > > > > Value* s = new ExtractElementInst(v1,3,"s",basicBlock); > > > > new ReturnInst(s,basicBlock); > > > > return func; > > } > > > > // modified from the fibonacci example > > int main(int argc, char **argv) > > { > > Module* pVectorModule = new Module(&quot...

...; >> >> Function::arg_iterator args = func->arg_begin(); >> >> Argument* x = args; >> >> x->setName("x"); >> >> >> >> Value* v1 = makeVector(x,4,basicBlock); >> >> >> >> Value* s = new ExtractElementInst(v1,3,"s",basicBlock); >> >> >> >> new ReturnInst(s,basicBlock); >> >> >> >> return func; >> >> } >> >> >> >> // modified from the fibonacci example >> >> int main(int argc, char **argv) &...

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

...k = new BasicBlock("body",func); > > > > Function::arg_iterator args = func->arg_begin(); > > Argument* x = args; > > x->setName("x"); > > > > Value* v1 = makeVector(x,4,basicBlock); > > > > Value* s = new ExtractElementInst(v1,3,"s",basicBlock); > > > > new ReturnInst(s,basicBlock); > > > > return func; > > } > > > > // modified from the fibonacci example > > int main(int argc, char **argv) > > { > > Module* pVectorModule = new Module(&q...

...gs = func->arg_begin(); >>> >>> Argument* x = args; >>> >>> x->setName("x"); >>> >>> >>> >>> Value* v1 = makeVector(x,4,basicBlock); >>> >>> >>> >>> Value* s = new ExtractElementInst(v1,3,"s",basicBlock); >>> >>> >>> >>> new ReturnInst(s,basicBlock); >>> >>> >>> >>> return func; >>> >>> } >>> >>> >>> >>> // modified from the fibonacci exa...

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

..., SelectInst ) // select instruction -HANDLE_OTHER_INST(50, UserOp1, Instruction) // May be used internally in a pass -HANDLE_OTHER_INST(51, UserOp2, Instruction) // Internal to passes only -HANDLE_OTHER_INST(52, VAArg , VAArgInst ) // vaarg instruction -HANDLE_OTHER_INST(53, ExtractElement, ExtractElementInst)// extract from vector -HANDLE_OTHER_INST(54, InsertElement, InsertElementInst) // insert into vector -HANDLE_OTHER_INST(55, ShuffleVector, ShuffleVectorInst) // shuffle two vectors. -HANDLE_OTHER_INST(56, ExtractValue, ExtractValueInst)// extract from aggregate -HANDLE_OTHER_INST(57, InsertValue...

...mns. What is a depth factor? Can you explain in the comment what this function calculates and not what happens when it is used. If you want to keep the use case, just put is an example. > + static inline size_t depthFactor(Value *v) { > + if (isa<InsertElementInst>(v) || isa<ExtractElementInst>(v)) { > + return 0; > + } No '{}' needed. > + > + return 1; > + } > + > + // Returns 1 if J accesses the memory directly after I; -1 if I accesses > + // the memory directly after J; and 0 otherwise. > + int getPairPtrInfo(Instruc...

...or? Can you explain in the > comment what this function calculates and not what happens when it is > used. If you want to keep the use case, just put is an example. > > > + static inline size_t depthFactor(Value *v) { > > + if (isa<InsertElementInst>(v) || isa<ExtractElementInst>(v)) { > > + return 0; > > + } > No '{}' needed. > > > + > > + return 1; > > + } > > + > > + // Returns 1 if J accesses the memory directly after I; -1 if I accesses > > + // the memory directly after J; and...

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in