search for: smallptrsets

hi, On Sat, Mar 17, 2012 at 2:11 AM, Andrew Trick <atrick at apple.com> wrote: > Yep. I normally do that. I was under some strange impression last night that SmallPtrSetImpl wasn't a template. The patch is incorrect because the SmallPtrSetImpl is neither a template nor has an "insert" function... After a detailed look at the header of SmallPtrSet, I found that the

Everyone, There is non-determinism in LLVM codegen in the following scenarios: 1. Between back-to-back runs of the same LLVM toolchain 2. Between Release vs Release+Asserts toolchains 3. Between Linux vs Windows toolchains The main reasons for the non-determinism in codegen are: 1. Iteration of unordered containers (like SmallPtrSet, DenseMap, etc) where the iteration order is undefined 2.

Everyone, The following patch to reverse iterate SmallPtrSet's has now been merged: https://reviews.llvm.org/D26718 This is how LLVM behavior will change due to this patch: - In LLVM builds with *assertions enabled*, SmallPtrSet's would always be reverse iterated by default. This default behavior can be overridden via the flag "-mllvm -reverse-iterate=<true/false>".

I see that the following test fails if reverse iteration of SmallPtrSet is enabled: /clang/test/SemaCXX/warn-loop-analysis.cpp/ This is because in SemaStmt.cpp we iterate SmallPtrSet and output warnings about the variables not used in the loop. Expected output: /warning: variables 'i', 'j', and 'k' used in loop condition not modified/ Output with reverse iteration:

On Tue, Dec 13, 2016 at 4:57 PM, Grang, Mandeep Singh via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Everyone, > > The following patch to reverse iterate SmallPtrSet's has now been merged: > https://reviews.llvm.org/D26718 > > This is how LLVM behavior will change due to this patch: > - In LLVM builds with assertions enabled, SmallPtrSet's would always be

On Tue, Dec 13, 2016 at 6:39 PM, Hans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 13, 2016 at 4:57 PM, Grang, Mandeep Singh via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Everyone, >> >> The following patch to reverse iterate SmallPtrSet's has now been merged: >> https://reviews.llvm.org/D26718 >> >> This is how LLVM

What are the rules regarding iterator stability for SmallPtrSet? I'm running into a problem where erasing an element seems to invalidate iterators that are not pointing at the erased element. Specifically, the set is in small mode, I advance an iterator to the last element in the set (not end(), but one before) and then erase the second-to-last element. I understand that the last element

> On 2016-Nov-15, at 15:16, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Mandeep Singh via llvm-dev Grang" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "mehdi amini" <mehdi.amini at apple.com>, dexonsmith at apple.com, zinob at codeaurora.org >> Sent: Tuesday, November 15, 2016

Hi all, Last year I had shared with the community my findings about instances of non-determinism in llvm codegen. The major source of which was the iteration of unordered containers resulting in non-deterministic iteration order. In order to uncover such instances we had introduced "reverse iteration" of unordered containers (currently only enabled for SmallPtrSet). I would now

Here's an actually working version of the change in the SelectionDAG cycle checking code to use SmallPtrSet. Again, apologies for royally screwing this one up. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: cyclecheck.patch Type: text/x-patch Size: 1598 bytes Desc: not available URL:

On Tue, 4 Dec 2007, David Greene wrote: > What are the rules regarding iterator stability for SmallPtrSet? > I'm running into a problem where erasing an element seems > to invalidate iterators that are not pointing at the erased element. Interesting question. > Specifically, the set is in small mode, I advance an iterator to the last > element in the set (not end(), but one

Thank you for the idea! Could you please explain it? If I’m not mistaken, you advise to insert the unknown insts of an every AS from AliasSetTracker::add(const AliasSetTracker &AST) into a smallptrset and consequently append it to merged alias sets from AliasSetTracker::findAliasSetForUnknownInst. I think that Philip proposed something similar to your approach in

On Tuesday 04 December 2007 13:28, Chris Lattner wrote: > > Specifically, the set is in small mode, I advance an iterator to the last > > element in the set (not end(), but one before) and then erase the > > second-to-last element. I understand that the last element will replace > > Right, deleting an element will invalidate any iterators past it, just > like a vector.

Hi Andy, I added the runStaticConstructorsDestructors and FindFunctionNamed functions. This also required making them virtual in EE.h. I'm not sure about FindFunctionNamed: In addition to searching finalized modules, should it search Added and Loaded modules? If it finds a Function in these, should it compile and finalize it before returning the Function* ? I modified the implementation

Dear llvm contributors, Could you please advise me how to skip checks, which are performed in AliasSet::aliasesUnknownInst, of unknown instructions from different alias sets of an alias set tracker that is a parameter of ‘AliasSetTracker::add(const AliasSetTracker &AST)’? If this wasn’t available at the moment and someone could review me, I would try to implement it. A temporary patch can be

Hi Yaron, Overall this looks great. There are a couple of remaining holes. Specifically, MCJIT inherits implementations of the FindFunctionNamed and runStaticConstructorsDestructors methods from ExecutionEngine which use the old Modules vector, so you'll need to override these in MCJIT. (The implementations are fairly trivial.) Beyond that I just have a couple of questions. First,

On Thu, Jul 6, 2017 at 8:02 AM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > > Grang, Mandeep Singh via llvm-dev > > Sent: Thursday, July 06, 2017 2:56 AM > > To: llvm-dev at lists.llvm.org > > Subject: [llvm-dev]

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 *

I did something similar for dominators, for GVN, etc. All see significant speedups. However, the answer i got back when i mentioned this was "things like ptrset and densemap should only have a small performance difference from side data when used and sized right", and i've found this to mostly be true after looking harder. In the case you are looking at, i see: -

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT