similar to: Error Calling eraseFromParent()

The code is really simple. But I can not the reason for the segmentation fault. I only know that the eraseFromParent() function leads to it. The whole code is: ... bool runOnFunction(Function &F) override { for (auto &I : instructions(F)) { if (auto* op = dyn_cast<BinaryOperator>(&I)) { IRBuilder<> builder(op); Value* lhs = op->getOperand(0); Value* rhs =

Hi. Thanks. I changed the code but the problem exists. This is my new code which is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder>

LLVM is built in Release mode. The version is 6.0.0. I think that a similar code worked on verison 3.9.0. It is probably a null pointer dereference occurring in eraseFromParent(). I checked and reconfirmed that the instruction had no uses. Perhaps I should rebuild LLVM. Thanks. On Wed, Aug 8, 2018 at 9:03 PM, mayuyu.io <admin at mayuyu.io> wrote: > Hmmmm that’s strange. Do you get an

Thanks Bjorn! But The problem is still there. On Wed, Aug 8, 2018 at 2:04 AM, Björn Pettersson A < bjorn.a.pettersson at ericsson.com> wrote: > It looks quite dangerous to erase the instruction I inside the loop when > iterating over all instructions in the function. > I guess it depends on how the range based iterator is implemented if that > works or not. > > I think

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

Hi all, I am almost ready for the last step with landing my long-standing patch. I have converted (almost) all low-level interface users of CallInst to respective high-level interfaces. What remains is a handful of hunks to flip the switch. But before I do the final commit I'd like to coerce all external users to code against the high-level interface too. This will (almost, but see below)

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

Sounds great to me Gabor. I really like your new incremental approach to this patch set. -Chris On Jun 30, 2010, at 1:59 PM, Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks >

Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks > to flip the switch. > > But before I do the final commit I'd like to coerce all external users > to code against the

I am confused by GlobalVariable::eraseFromParent's declaration: /// This method unlinks 'this' from the containing module and deletes it. void eraseFromParent(); In Globals.cpp the unlinking is done and SymbolTableListTraits cleans up the symbol table but I don't see anything that actually deletes the object. Is the comment misleading or am I missing something?

Thank you Ahmad, I figured out that, although the type of both p(oInst) and p(nInst) were the same, I had to: for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) { callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType()); } that solves the issue at the calling instruction in the main function, but now I see that *linkModules* does not work

Hi, I am trying to replace a global variable with a constant. I did manage to do it, but somehow it appears to be fairly bruteforce by just iterating over all functions/bblocks/instructions and filtering for those that load the variable and replacing the instruction with Instruction::replaceAllUsesWith(). The more intuitive way of iterating over the uses of the variable did not work out as I

Alysson wrote: > Hi LLVMers, > > I am working on my llvm school project optimization pass. It's > relatively simple, and it tries to remove redundant bitcast instructions > followed by load instructions. At first, I'm using as input a bytecode > generated by a simple Java test program. > I've already found the reduntant instructions by looking at it's

Hi Ahmad, What does that tool does besides what LLVM linker already does? I don't think my problem is in linking both modules, I think LLVM linker does the job for me, the issue is when changing the called function to call another function (in the example previously provided, to change it from foo2 to foo3, and adjusting the function parameter's references). Regards, Daniel Moya El

On Apr 16, 2008, at 2:50 AM, heisenbug wrote: > > And now here is my educated speculation: > There are 2 things that became slower > 1) Use::getUser() > 2) Use::get/set due to tagging. > > The former is seldom called: > > $ find lib -name "*.cpp" | xargs grep "getUser(" | wc -l > 41 The majority of those aren't actually Use::getUser, but

On Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with

Hi I have checked all blocks, each block have a Terminator instruction and each blocks belongs to a function. I'm really confused. I guess the problem is caused by the removal of the Loop,The code is as follows: * //every block to header (except the ones in the loop), will now redirect to newblock for (pred_iterator PI = pred_begin(header); PI != pred_end(header); ++PI) {

On Wed, Oct 21, 2015 at 1:21 PM Alexey Samsonov <vonosmas at gmail.com> wrote: > On Wed, Oct 21, 2015 at 12:59 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> >> >> On Wed, Oct 21, 2015 at 12:17 PM Alexey Samsonov <vonosmas at gmail.com> >> wrote: >> >>> We have out-of-tree implementation of llvm-symbolizer-as-a-library,

Hi LLVMers, I am working on my llvm school project optimization pass. It's relatively simple, and it tries to remove redundant bitcast instructions followed by load instructions. At first, I'm using as input a bytecode generated by a simple Java test program. I've already found the reduntant instructions by looking at it's CFG, and I also could implement the code to

Hi, I want to convert a function pointer call in the IR of MPlayer to a function call. For example, I have the following line: ... %10 = tail call i32 %7(%struct.demuxer* nonnull %0, i32 %1, i8* %2) #7, !dbg !863222 ... I want to set the target which is stored in %7 to a real function called "demux_lavf_control()" with the following definition: ... define internal i32