similar to: DCE in the presence of control flow.

Thanks Also I found that some cases are also caught by a specialized routine to remove dead loops which is missing the case I noticed. odavd From: Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> Date: Thursday, January 28, 2016 at 8:45 PM To: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>>, LLVM Dev Mailing list <llvm-dev at

On Thu, Jan 28, 2016 at 10:09 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Daniel Berlin" <dberlin at dberlin.org>, "LLVM Dev Mailing list" < > llvm-dev at lists.llvm.org> > *Sent: *Thursday, January 28, 2016

I think you can also avoid the RDF computation using a more directed form of control dependence testing such as described in Keshav Pingali and Gianfranco Bilardi. 1997. Optimal control dependence computation and the Roman chariots problem. ACM Trans. Program. Lang. Syst. 19, 3 (May 1997), 462-491. DOI=http://dx.doi.org/10.1145/256167.256217 However one challenge seems to be fixing the SSA graph

In practice, APT is not faster to build than rdf. The df calculator we use is linear time and quite fast. Updating is also pretty trivial since it's only deletes of dead and unreachable code. So anything it reached can be replaced with undef in most cases. Cd-dce is not slower in GCC than dce On Fri, Jan 29, 2016, 8:31 PM David Callahan <dcallahan at fb.com> wrote: > I think you

I had assumed you would treat phi nodes differently from other operations in that they don’t need to keep the block alive just to retain the data flow facts but it would be simplest to do that. Thanks Daniel From: Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> Date: Friday, January 29, 2016 at 10:26 PM To: David Callahan <dcallahan at

Maybe I was too quick here. Does gcc record the incoming edge to a phi? If so, won’t those change when you delete blocks in a non-trivial manner? How are those updated? From: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>> Date: Saturday, January 30, 2016 at 7:02 AM To: Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>>, Hal Finkel

Hi, All I want to implement DSWP Which is used for parallelization of loops. For this purpose, the loop was replaced with a new basic block in main function. And new functions were created and basic blocks of Loop assigned to them.I have checked blocks and branches for Succ and Pred relation and I have not found any problems. However I get the following error: * **opt:

Some question: 1. IDFCalculator already allows reverse graphs, and gets used for that, so what did you have to change? (this change was made in the past year, so i wonder if you were working on a branch or something). 2. What are the actual numbers here in terms of calculation of IDF vs your method. IDF calculator is linear time (Well, depends on priority queue impl, but we could fix that

On Mon, Apr 4, 2016 at 11:49 AM, David Callahan <dcallahan at fb.com> wrote: > > I may have not correctly used the IDFCalculator. I passed in the > PostDominator tree and then changed the loop over successor blocks to also > be able to iterate over predecessors. I did not see anything in the > interface that would let that happen but perhaps I don’t understand the API > so

On Fri, Mar 25, 2016 at 3:52 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Daniel Berlin" <dberlin at dberlin.org> > *Cc: *"David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Friday, March 25, 2016

Hi, I have a new variant of Aggressive Dead Code Elimination that also removes dead branching. It is designed to minimize the cost of control-dependence analysis in the common case where almost the entire program is live. It also can optionally remove dead but may-be-infinite loops. When enabled for –O3 (replacing current ADCE pass) and removing loops, impact on SPEC2006 is in the noise but it

Hi Daniel, Daniel Berlin wrote: > /* Add fake edges to the function exit for any non constant and non > noreturn calls (or noreturn calls with EH/abnormal edges), > volatile inline assembly in the bitmap of blocks specified by > BLOCKS > or to the whole CFG if BLOCKS is zero. > ... > > The goal is to expose cases in

On Fri, Jul 15, 2016 at 4:00 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jul 15, 2016, at 3:38 PM, Sanjoy Das <sanjoy at playingwithpointers.com> > wrote: > > > Note that this is also necessary to makes post-dominance correct (but we > > already do it in most cases, but i think there are still bugs open about > > correctness) > > Yeah,

[+Danny] ----- Original Message ----- > From: "Justin Bogner via llvm-dev" <llvm-dev at lists.llvm.org> > To: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, March 23, 2016 12:36:50 PM > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination pass > > David Callahan via llvm-dev <llvm-dev at

(and sys::cas_flag that STATISTIC uses is a uint32 ...) On Thu, Aug 25, 2016 at 9:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > Okay, dumb question: > Are you really getting negative numbers in the second column? > > 526,766 -136 mem2reg # PHI nodes inserted > > http://llvm.org/docs/doxygen/html/PromoteMemoryToRegister_8cpp_source.html >

Under what circumstances will a TerminatorInst will have multiple successors? The three methods: virtual BasicBlock *getSuccessorV(unsigned idx) const = 0; virtual unsigned getNumSuccessorsV() const = 0; virtual void setSuccessorV(unsigned idx, BasicBlock *B) = 0; are defined for the TerminatorInst class, but I cannot see why a terminator is allowed to go to different targets. Thanks,

Hi LLVMers, I can't figure out why these errors exits: ------------------------- llvm[2]: Linking Debug executable opt c:/projects/build/MinGW/llvm-4-1/Debug/lib/LLVMProfilePaths.o(.text$_ZN4llvm10BranchInstC1EPNS_10BasicBlockES2_+0x52): In function `ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPN4llvm8FunctionEPNS3_5GraphEEEE10deallocateEPSA_j':

> On Mar 25, 2016, at 3:30 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Make most things update post-dominance info and preserve it. > > Our other alternative to not take up too much time seems to be invasive surgery on how BB successors/predecessors work so they are a constant time array. I say this because GCC recomputes post-dominators roughly

David Callahan via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi, > > I have a new variant of Aggressive Dead Code Elimination that also > removes dead branching. It is designed to minimize the cost of > control-dependence analysis in the common case where almost the entire > program is live. It also can optionally remove dead but > may-be-infinite loops. > >

I am building code which needs to examine dominating relationships between Basic Blocks. I searched the Programming Guide (http://llvm.org/docs/ProgrammersManual.html#common), it mentioned briefly that such details will be covered in the future. So, I am tuning to the list and ask. Say, I have BasicBlock * a, *b, and need to know whether a DOM b, (a DOMi b, a DOMp b, a PostDOM b), etc. How