similar to: [LLVMdev] [PATCH] trivial: remove unused variable

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

On Oct 6, 2011, at 17:19, Yiannis Tsiouris wrote: > Hello all, > > I set: InitRoots = true; in my gc plugin as i want the roots to be > initialized to the "null" value. > Is there a way to define which value should be the initial one? For > example, i would like to initialize my roots to -5 (tagged, null value > for the GC in my runtime system) instead of 0. >

I have no idea why this code compiled correctly with gcc... m. Index: include/llvm/ADT/SetVector.h =================================================================== RCS file: /var/cvs/llvm/llvm/include/llvm/ADT/SetVector.h,v retrieving revision 1.8 diff -u -r1.8 SetVector.h --- include/llvm/ADT/SetVector.h 11 Sep 2004 20:38:25 -0000 1.8 +++ include/llvm/ADT/SetVector.h 13

Hi:    I want to do some optimization on MachineLoop. So I want to get MachineLoopInfo from MachineFunction. I reference MachineLICM.cpp. So I try to write a pass in Target/mytarget directory. I find there is Error. llvm/include/llvm/PassAnalysisSupport.h:198: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::MachineLoopInfo]: Assertion

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F

Hello, > On Oct 28, 2008, at 10:10 AM, 谭明星 wrote: >> >> PS: The following are links about this paper: >> http://portal.acm.org/citation.cfm?id=1356064 >> http://www.if.insa-lyon.fr/chercheurs/jpbabau/emsoc/presentations/EmSoC07_Boissinot.pdf >> I've put the slides from CGO online:

UniqueVector is an stl map coupled with an stl vector[1], which seems very undesirable for you. As far as SmallVector + slow search, I believe that is precisely what the implementation of SmallSet does until it has to grow, after which it uses an stl set[2]. If you're always staying within your small number, SmallSetVector would be wasteful as the SmallSet would itself also have a SmallVector.

LLVM has two similar bits of infrastructure: a simplifyInstructionsInBlock function and a SimplifyInstructions pass, both intended to be lightweight “fix up this code without doing serious optimizations” functions, as far as I can tell. I don’t think either is used in a performance-sensitive place in-tree; the former is mostly called in minor places when doing CFG twiddling, and the latter seems

Mingxing, Your project sounds interesting and if it significantly improves over the live variable analysis that is in LLVM right now, I think it could be a useful contribution. I'm copying the 'llvmdev at cs.uiuc.edu' mailing list, which you should join. Send all related messages to this list to get feedback on your goals and also to get help with any problems you face.

Hi, Benoit, Thanks very much for your advice. You see the algorithm greatly improve the performance of liveness analysis. However, it seems still not efficient. First, it is inefficient in space. You have to pre-compute all Tq for every Tq and save them, even though only the highest nodes of Tq are needed for a given query(q,v); Second, it is inefficient in time. Given any query(q,v), you have to

From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm compiles fine; ours is compiled to a Debugging version. llvm-gcc, though, is angry. I get the following error (with path prefixes shortened for convenience) when compiling llvm-gcc: > In file included from

Hi, Dear Boissinot: 1. When I have irreducible CFG, I travel its nodes by DFS. search backedge for every node. After I finish one node, push it into a stack. [0, 1, 2, M] <---push. [0, 1, 2, M,...N] <---push. When resolving node M, find a edge from node N to node M, N is not in stack(M < N), It is a backedge. N is in stack(M > N), It is NOT a backedge.

This is an excellent project. We look forward to seeing your work! Is it possible for you to implement your work on the mainline and contribute back patches along the way? That way, the community can offer suggestions and we will try *harder* not to break your pass. Evan On Oct 29, 2008, at 10:39 PM, Star wrote: > Hi, Benoit, > Thanks very much for your advice. > You see the

Thank you, Nick. Yes, I have add getAnalysisUsage. As I know, some CFG is irreducible. At this time, Dominator Tree can not find some backedge. Is it means some MachineLoop is not be found? dominatorTree.jpg is a previous exmaple. best regards! renkun --- 10年3月9日，周二, Nick Lewycky <nicholas at mxc.ca> 写道： > 发件人: Nick Lewycky <nicholas at mxc.ca> > 主题: Re: [LLVMdev] Find

Hi, Evan. I'm new in LLVM project developing. How should I work on the mainline? I have check out the latest copy of LLVM from Subvresion using the Read-Only account. Do you mean I should provide the patch to the mainline periodic in this LLVMDEV mailing list? Anyway, thanks for your advice :) Star > -----Original Message----- > From: Evan Cheng [mailto:evan.cheng at apple.com] >

On 08/13/2009 07:35 PM, Matt Elder wrote: > From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm > using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm > compiles fine; ours is compiled to a Debugging version. llvm-gcc, > though, is angry. I get the following error (with path prefixes > shortened for convenience) when compiling llvm-gcc:

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the

On Fri, Jan 08, 2010 at 05:04:17PM -0800, Chris Lattner wrote: > On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > >Hello, > > > >The CodeExtractor contains a std::set<BasicBlock*> to keep track > >of the > >blocks to extract. Iterators on this set are not deterministic, and so > >the functions that are generated are not (the order of the >

On Sun, Mar 29, 2009 at 3:33 PM, Benoit Boissinot <bboissin+llvm at gmail.com> wrote: > While it is not described in the litterature, I don't think you need > to introduce a new > function: >      x0 = ... >  x1, x2 = \sigma (x0) >         | >    +----+------+ >    |           | >    v           v >  ... = x1    ... = x2 > > Can be transformed to: >

On Mon, Mar 30, 2009 at 1:05 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Mar 29, 2009 at 3:33 PM, Benoit Boissinot > <bboissin+llvm at gmail.com> wrote: >> While it is not described in the litterature, I don't think you need >> to introduce a new >> function: >>      x0 = ... >>  x1, x2 = \sigma (x0) >>         | >>