search for: worklists

...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 worklist. Note: I am not concerned about

...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 defi...

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-use chain?

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

Thank you David for prompt reply. I tried with SmallVector. I inserted elements with push_back(). But when I retrieve elements using pop_back_val the elements are returned in reverse order of insertion (I mean like LIFO order). I need this to be FIFO order. How to achieve that? Regards, Rekha On Sun, Nov 3, 2013 at 8:31 PM, David Blaikie <dblaikie at gmail.com> wrote: > If you

...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.begin...

On Wed, Oct 16, 2013 at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 1:21 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> There are a few places where we break the assumption: >> 1> formal_parameter constructed in DwarfDebug when adding attribute type >> we call SPCU->addType(Arg, ATy),

On Wed, Oct 16, 2013 at 9:10 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> >> On Wed, Oct 16, 2013 at 1:21 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> There are a few places where we break the assumption:

On Sun, Nov 3, 2013 at 7:38 AM, Rekha R <rekharamapai at nitc.ac.in> wrote: > Thank you David for prompt reply. > > I tried with SmallVector. I inserted elements with push_back(). > But when I retrieve elements using pop_back_val the elements are returned > in reverse order of insertion (I mean like LIFO order). > I need this to be FIFO order. How to achieve that? >

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

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 Davé

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

On Wed, Oct 16, 2013 at 10:32 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 9:10 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Wed, Oct 16, 2013 at 1:58 PM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> >>> >>> On Wed, Oct 16, 2013 at

Hello all, I am a LLVM newer who want to obtain the use-def chain for all instruction of a sample code, for this purpose i use the following code. ///////////////sample code:///////////////////////// #include <stdlib.h> #include <stdio.h> #include <time.h> #define ARRAY_SIZE 5 int main() { int x, y, holder; int k,z,f,i; z=0; f=0; k=0; for(x = 0; x < ARRAY_SIZE;

On Wed, Oct 16, 2013 at 1:21 PM, Manman Ren <manman.ren at gmail.com> wrote: > > There are a few places where we break the assumption: > 1> formal_parameter constructed in DwarfDebug when adding attribute type > we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. > 2> inlined_subroutine constructed in DwarfDebug when adding attribute >

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...

...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), >...

> > 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