search for: worklist

...we were calling simplifyInstructionsInBlock on the entire function to clean things up before another pass. This turns out to be quite costly: the function is not very efficient, tends to revisit instructions more than is necessary, and spends a lot of time constructing weak handles and handling its worklists. I wrote a new version of it that is about ~3x faster and reduced our total compilation time by about 2%. The new version is very very fast: it’s a full-function simplify-and-DCE that looks to be about twice as fast as comparatively “fast” passes like ADCE — fast enough that I can imagine plopping...

Hi, I am writing an analysis which requires creating worklist of basic blocks. The worklist should be in FIFO order. I checked SmallVector (and similar others) and found out this is working in LIFO order when I use the functions push_back and pop_back_val to insert and delete elements in the worklist. Can someone suggest an appropriate DS to implement my wor...

...truction* itself, rather than a reference to the > pointer. This would make it work the same as standard ilist iterators. Yes, I though about this appoach as well but decided it can be too disturbing for other code. > The reason why we have it return pointers right now is to populate > worklists, which allows us to do: > > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F)); Maybe this can be rewritten like; std::set<Instruction*> WorkList; std::transform(insn_begin(F), insn_end(F), inserter(WorkList, WorkList.begin(), take_address); given proper def...

Hi, I copied the code from LLVM2.6 below. line 81 removes 'I' from the worklist. But 'I' is already removed from the list at line 67 when it is popped from the list. Could the loop (line 73-75) insert this I into the worklist again? In the case where 'I' can be constant-folding, Line 80 says 'I' is a dead instruction. Can 'I' appears in its def...

If you don't care about efficiency you can push (or at least insert) at the front of a(small or otherwise) vector. On Nov 3, 2013 3:32 AM, "Rekha R" <rekharamapai at nitc.ac.in> wrote: > Hi, > > I am writing an analysis which requires creating worklist of basic blocks. > The worklist should be in FIFO order. I checked SmallVector (and similar > others) and found out this is working in LIFO order when I use the > functions push_back and pop_back_val to insert and delete elements in the > worklist. > > Can someone suggest an appro...

...If you don't care about efficiency you can push (or at least insert) at > the front of a(small or otherwise) vector. > On Nov 3, 2013 3:32 AM, "Rekha R" <rekharamapai at nitc.ac.in> wrote: > >> Hi, >> >> I am writing an analysis which requires creating worklist of basic >> blocks. The worklist should be in FIFO order. I checked SmallVector (and >> similar others) and found out this is working in LIFO order when I use the >> functions push_back and pop_back_val to insert and delete elements in the >> worklist. >> >> Can...

...the same as standard ilist iterators. > > Yes, I though about this appoach as well but decided it can be too disturbing > for other code. I think it's the most correct and consistent want to do it. > > The reason why we have it return pointers right now is to populate > > worklists, which allows us to do: > > > > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F)); > > Maybe this can be rewritten like; > > std::set<Instruction*> WorkList; > std::transform(insn_begin(F), insn_end(F), > inserter(WorkList, WorkList.begi...

...om outside the CU) and we might want to say that it's so > important that your patch shouldn't violate it - but I'm not sure that's > necessary (Eric?). I haven't given it a great deal of thought. > Patches are reattached for convenience: remove DIE duplication with a worklist (name it patch_with), remove DIE duplication without a worklist but an assertion when we emit a ref4, we make sure the DIE and the referenced DIE belong to the same CU (name it patch_without). Without my patch, the assumption may be true, but it does not matter since we should always use ref4. I h...

...t want to say that it's so >> important that your patch shouldn't violate it - but I'm not sure that's >> necessary (Eric?). I haven't given it a great deal of thought. >> > > > Patches are reattached for convenience: remove DIE duplication with a > worklist (name it patch_with), remove DIE duplication without a worklist > but an assertion when we emit a ref4, we make sure the DIE and the > referenced DIE belong to the same CU (name it patch_without). > OK, we're going round in circles here and I'm not sure there are many other ways I...

...out efficiency you can push (or at least insert) at >> the front of a(small or otherwise) vector. >> On Nov 3, 2013 3:32 AM, "Rekha R" <rekharamapai at nitc.ac.in> wrote: >> >>> Hi, >>> >>> I am writing an analysis which requires creating worklist of basic >>> blocks. The worklist should be in FIFO order. I checked SmallVector (and >>> similar others) and found out this is working in LIFO order when I use the >>> functions push_back and pop_back_val to insert and delete elements in the >>> worklist. >&g...

hi all this works <%= render :partial => "admin/works/work", :collection => @artist.works %> but this doesn''t <%= render :partial => "admin/works/worklist", :collection => @artist.works %> even though the partial _work.rhtml and _worklist.rhtml are identical. worklist.rhtml throws undefined local variable or method `work'' Extracted source (around line #2): 1: <tr> 2: <td><%= link_to work.short...

The root problem is that, when A gets modified, D doesn't get added back to the worklist. I could match the pattern on A, but the problem remains: when D gets modified, A do not get added back tot he worklist. I also considered ding several round of DAGCombine, but it is very easy to run into infinite loops, even with a fair amount of sanity checks. 2017-05-22 7:30 GMT-07:00 Nirav Da...

Explicitly re-adding a node to be processed doesn't work, because the processing order is canonical. 2017-05-22 11:39 GMT-07:00 Nirav Davé <niravd at google.com>: > You can always explicitly add D to the worklist when you make the > transformation with AddToWorklist. Presuambly this was the cause for your > infinite loop. > > -Nirav > > > On Mon, May 22, 2017 at 2:07 PM, Amaury SECHET <deadalnix at gmail.com> > wrote: > >> The root problem is that, when A gets modified...

...so >>> important that your patch shouldn't violate it - but I'm not sure that's >>> necessary (Eric?). I haven't given it a great deal of thought. >>> >> >> >> Patches are reattached for convenience: remove DIE duplication with a >> worklist (name it patch_with), remove DIE duplication without a worklist >> but an assertion when we emit a ref4, we make sure the DIE and the >> referenced DIE belong to the same CU (name it patch_without). >> > > OK, we're going round in circles here and I'm not sure there...

...t; ARRAY_SIZE-1; y++) if(x+y>10) { holder = x+y; k=z+1; f=k+x; if (i>k) i=i+1; } // return 1; } ////////////////////////pass code:///////////////////////////////// virtual bool runOnFunction(Function &F) { std::vector<Instruction*> worklist; for(inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I){ worklist.push_back(&*I); } for(std::vector<Instruction*>::iterator iter = worklist.begin(); iter != worklist.end(); ++iter){ Instruction* instr = *iter;...

...it's so important that your patch shouldn't violate it - but I'm not sure that's necessary (Eric?). I haven't given it a great deal of thought. > As I stated earlier, this assumption, in my opinion, is not really > general, and if we only make this assumption to remove a worklist, it may > not worth it. > There is still no discussion about "removing the worklist" - the only discussion is about whether we need to /add/ the worklist. It's up to the commiter to justify the addition of code, not for the community to justify its removal. (I'd say this is...

I'm trying to optimize a pattern that goes roughly as: A / \ B C \ / D Problem is, when A gets modified, B and C get added back to the worklist, but D doesn't. Readding D to the worklist just create an infinite loop where one process D again and again. Is there a proper way to make this work ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201705...

...ake any sense. Probably the right thing to do would be to make the inst_iterator return a reference to the *instruction* itself, rather than a reference to the pointer. This would make it work the same as standard ilist iterators. The reason why we have it return pointers right now is to populate worklists, which allows us to do: std::set<Instruction*> WorkList(inst_begin(F), inst_end(F)); Which is nice. What do you think? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

...> > > Yes, I though about this appoach as well but decided it can be too > > disturbing for other code. > > I think it's the most correct and consistent want to do it. Great. > > > The reason why we have it return pointers right now is to populate > > > worklists, which allows us to do: > > > > > > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F)); > > > > Maybe this can be rewritten like; > > > > std::set<Instruction*> WorkList; > > std::transform(insn_begin(F), insn_end(F), &gt...

> > Instead of adding the operands to a list, erase the instruction and add them to the worklist wouldn’t be probably faster something like: > > if (Instruction *Used = dyn_cast<Instruction>(*OI)) > if (Used->hasOneUse()) > WorkList.insert(Used); > > If it has one use is going to be the instruction we are going to remove anyway, right? I don’t think this is...