search for: getoperandno

...part of my code: ... if (auto* op = dyn_cast<BinaryOperator>(&I)) { Value* lhs = op->getOperand(0); Value* rhs = op->getOperand(1); Value* mul = builder.CreateMul(lhs, rhs); for (auto& U : op->uses()) { User* user = U.getUser(); user->setOperand(U.getOperandNo(), mul); } I.eraseFromParent(); } ... This leads to the following runtime error: LLVMSymbolizer: error reading file: No such file or directory ... Does anybody know the solution? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.or...

...t++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder> builder(op); Value* lhs = op->getOperand(0); Value* rhs = op->getOperand(1); Value* mul = builder.CreateMul(lhs, rhs); for (auto& U : op->uses()) { User* user = U.getUser(); user->setOperand(U.getOperandNo(), mul); } //I->eraseFromParent(); dels.push_back(I); } } for (auto &I : dels) { I->eraseFromParent(); } ... On Wed, Aug 8, 2018 at 6:16 PM, mayuyu.io <admin at mayuyu.io> wrote: > Hi: > As stated in the documentation you shouldn’t modify it while iterating as > this inv...

...ns(F)) { if (auto* op = dyn_cast<BinaryOperator>(&I)) { IRBuilder<> builder(op); Value* lhs = op->getOperand(0); Value* rhs = op->getOperand(1); Value* mul = builder.CreateMul(lhs, rhs); for (auto& U : op->uses()) { User* user = U.getUser(); user->setOperand(U.getOperandNo(), mul); } I.eraseFromParent(); } } ... And I think that the code worked well with LLVM-3.6.0 that I tested one year ago. Now, I use LLVM-6.0.0. Regards. On Tue, Aug 7, 2018 at 8:11 PM, <paul.robinson at sony.com> wrote: > LLVMSymbolizer is invoked while trying to pretty-print a cr...

...rator>(I)) { > IRBuilder<NoFolder> builder(op); > > Value* lhs = op->getOperand(0); > Value* rhs = op->getOperand(1); > Value* mul = builder.CreateMul(lhs, rhs); > > for (auto& U : op->uses()) { > User* user = U.getUser(); > user->setOperand(U.getOperandNo(), mul); > } > //I->eraseFromParent(); > dels.push_back(I); > } > } > > for (auto &I : dels) { > I->eraseFromParent(); > } > ... > > On Wed, Aug 8, 2018 at 6:16 PM, mayuyu.io <admin at mayuyu.io> wrote: > >> Hi: >> As stated in the...

...Operator>(&I)) { > IRBuilder<> builder(op); > > Value* lhs = op->getOperand(0); > Value* rhs = op->getOperand(1); > Value* mul = builder.CreateMul(lhs, rhs); > > for (auto& U : op->uses()) { > User* user = U.getUser(); > user->setOperand(U.getOperandNo(), mul); > } > > I.eraseFromParent(); > } > > } > ... > And I think that the code worked well with LLVM-3.6.0 that I tested one > year ago. Now, I use LLVM-6.0.0. > Regards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <ht...

...st harness change the result of the tests? SDUse::setInitial should initialize List to null in your patch. You're probably seeing random uninitialized data noise without that. (Though valgrind wouldn't notice this because of the aggressive reuse of allocated memory.) Also, the replacement getOperandNo is returning the index in the use list, rather than the index in the operand array. Dan

...clients the chance to use *ArgOperand* versions. This will be well-commented in the header, explaining the recommended way of accessing arguments. At this point we will have caught 99% of all low-level clients out there. What uncertainties will remain? I can think of two of them: o getOperandNo() o access via baseclass pointer The former is a method on Value::use_iterator and I cannot see a way to intercept it at compile-time. The latter is always possible and does circumvent the above measures, there is no remedy against it. I plan to fire each of these two rounds with one week dela...

Hi everyone, Instruction and Value classes have "Uses" and "User". What is the difference between them? I think that "Uses" gives all the instructions/values that a particular Value depends on and "User" gives all the instructions/values that depend on that particular value. Is that right? Best, Carlo -------------- next part -------------- An HTML

...n_cast<CallInst>(I) somewhere in "method". Cheers, Gabor > > -- John T. > >> At this point we will have caught 99% of all low-level clients >> out there. >> >> What uncertainties will remain? I can think of two of them: >> >> o getOperandNo() >> o access via baseclass pointer >> >> The former is a method on Value::use_iterator and I cannot see a >> way to >> intercept it at compile-time. >> The latter is always possible and does circumvent the above measures, >> there is no remedy against...

...CallInst * CI) { method (CI); ... } Will method() still work when you make CallInst::getOperand() private? -- John T. > At this point we will have caught 99% of all low-level clients out > there. > > What uncertainties will remain? I can think of two of them: > > o getOperandNo() > o access via baseclass pointer > > The former is a method on Value::use_iterator and I cannot see a way to > intercept it at compile-time. > The latter is always possible and does circumvent the above measures, > there is no remedy against it. > > I plan to fire each...

...versions. This will be well-commented in the > header, explaining the recommended way of accessing > arguments. > > At this point we will have caught 99% of all low-level clients out > there. > > What uncertainties will remain? I can think of two of them: > > o getOperandNo() > o access via baseclass pointer > > The former is a method on Value::use_iterator and I cannot see a way to > intercept it at compile-time. > The latter is always possible and does circumvent the above measures, > there is no remedy against it. > > I plan to fire each...

..., > > Gabor > > > >> -- John T. >> >> >>> At this point we will have caught 99% of all low-level clients >>> out there. >>> >>> What uncertainties will remain? I can think of two of them: >>> >>> o getOperandNo() >>> o access via baseclass pointer >>> >>> The former is a method on Value::use_iterator and I cannot see a >>> way to >>> intercept it at compile-time. >>> The latter is always possible and does circumvent the above measures, >>&gt...

...if we can modify the type of CI. This + // requires that any uses of it should be modifiable. For now, we'll just + // propagate if all uses are loads and stores. + for (User::use_iterator I = CI.use_begin(), E = CI.use_end(); I != E; ++I) { + if (isa<StoreInst>(*I)) { + if (I.getOperandNo() != StoreInst::getPointerOperandIndex()) + return 0; // Can only handle store to this pointer + } else if (isa<GetElementPtrInst>(*I)) { + if (I.getOperandNo() != GetElementPtrInst::getPointerOperandIndex()) + return 0; + } else if (!isa<LoadInst>(*I)) { +...

...tests? > > SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) > > Also, the replacement getOperandNo is returning the index in the > use list, rather than the index in the operand array. Yes. David, to clarify, what do you see with a *clean checkout* with no patches in it? -Chris

...ninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) Why isn't the default constructor called? I would have expected that to be invoked for every new SDUse. I will fix this. > Also, the replacement getOperandNo is returning the index in the > use list, rather than the index in the operand array. Thanks. I don't have the source right in front of me. I'll take a look when I can. -Dave

On Thursday 25 February 2010 16:17:10 David Greene wrote: > On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: > > On Feb 25, 2010, at 12:01 PM, David Greene wrote: > > > I am seeing a whole lot of failures in the tests on trunk. From > > > discussions with Chris and others, I should not be seeing this. > > > > Does 'make check-lit' pass for

...mented in the >> header, explaining the recommended way of accessing >> arguments. >> >> At this point we will have caught 99% of all low-level clients out >> there. >> >> What uncertainties will remain? I can think of two of them: >> >> o getOperandNo() >> o access via baseclass pointer >> >> The former is a method on Value::use_iterator and I cannot see a >> way to >> intercept it at compile-time. >> The latter is always possible and does circumvent the above measures, >> there is no remedy against...

...> + // requires that any uses of it should be modifiable. For now, > we'll just > + // propagate if all uses are loads and stores. > + for (User::use_iterator I = CI.use_begin(), E = CI.use_end(); I ! > = E; ++I) { > + if (isa<StoreInst>(*I)) { > + if (I.getOperandNo() != StoreInst::getPointerOperandIndex()) > + return 0; // Can only handle store to this pointer > + } else if (isa<GetElementPtrInst>(*I)) { > + if (I.getOperandNo() != > GetElementPtrInst::getPointerOperandIndex()) > + return 0; > + } else if (!i...

On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: > On Feb 25, 2010, at 12:01 PM, David Greene wrote: > > I am seeing a whole lot of failures in the tests on trunk. From > > discussions with Chris and others, I should not be seeing this. > > Does 'make check-lit' pass for you in llvm/test? Nope. In fact I am seeing more failures in debug mode now. But what

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for