similar to: [LLVMdev] [llvm-commits] Review Request: Use SmallPtrSetImpl instead of SmallPtrSet in funciton IVUsers::AddUsersIfInteresting

Hi all, I have a compilation failure with 'insert' member function of SmallPtrSetImpl class because the return value is changed from r222334. But the comment of the function is same with before as follows: /// insert - This returns true if the pointer was new to the set, false if it /// was already in the set. std::pair<iterator, bool> insert(PtrType Ptr) { auto p

I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then use that to build a Debug+Asserts version. Include all of the bells and whistles, like the clang-extras and compiler-rt libraries. The reason I suspect debug info is because of this stack trace: [morbo:llvm]

Hi Bill Is this a recent regression? I recently changed the debug info verifier to fix a bug. Thanks, Manman > On Nov 17, 2013, at 5:52 PM, Bill Wendling <isanbard at gmail.com> wrote: > > I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then

Hi Bill, Thanks for the testing case. Most of the time is spent on debug info verifier. I fixed a bug in r194974, now it takes too long to run debug info verification. Debug info verifier is part of the verifier which is a Function Pass. Tot currently tries to pull all reachable debug info MDNodes in each function, which is too time-consuming. The correct fix seems to be separating debug info

I think it might be. I’m attaching a preprocessed file that can show the problem. Compile it with ToT. $ clang++ -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcovered-switch-default -Wno-uninitialized -Wno-missing-field-initializers -c

On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi Bill, > > Thanks for the testing case. Most of the time is spent on debug info > verifier. > I fixed a bug in r194974, now it takes too long to run debug info > verification. > > Debug info verifier is part of the verifier which is a Function Pass. Tot > currently tries to pull all

On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com>wrote: > On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi Bill, > > > > Thanks for the testing case. Most of the time is spent on debug info > > verifier. > > I fixed a bug in r194974, now it takes too long to run debug info > >

Hi Tim, > From: Tim Creech <tcreech at umd.edu> > Subject: [LLVMdev] IVUsers (LoopPass) analysis in a ModulePass? > Date: September 1, 2011 11:46:28 AM PDT > To: llvmdev at cs.uiuc.edu > > Hi all, > I have a loadable ModulePass which does transformations, and I would like to > use IVUsers analysis within it. I noticed when I try to do this (via > the usual

Linking CXX executable ../../../../bin/lldb Scanning dependencies of target lldb-platform [100%] Building CXX object tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o *../../../../lib/liblldb.so.3.5: undefined reference to `llvm::SmallPtrSetImpl::SmallPtrSetImpl(void const**, unsigned int, llvm::SmallPtrSetImpl&&)'** **clang: error: linker command

This series of patches address several issues causing memory usage to grow indefinetely on a long lived process. These are not convenional leaks -- memory would have been freed when the LLVM context or/and JIT engine is destroyed -- but for as long as they aren't the memory is usage effectively ubounded. The issues were found using valgrind with '--show-reachable=yes' option: 1.

Looks like your lldb is being compiled in C++11 mode and your llvm wasn't perhaps? -eric On Sat, Nov 23, 2013 at 12:57 AM, Marc Driftmeyer <mjd at reanimality.com> wrote: > Linking CXX executable ../../../../bin/lldb > Scanning dependencies of target lldb-platform > [100%] Building CXX object > tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

Hi all, I’ve most recently been grappling with a difficult to reproduce bug. I’ve traced the source of the difficulty in reproduction to the IVUsers analysis pass that is used by Loop Strength Reduction. Specifically, the IVUsers pass’s output is very sensitive to both the use list ordering of the instructions that it is looking at and the ordering of the Phi nodes in the header block of the loop

On 09/14/2017 10:31 PM, Daniel Neilson wrote: > > >> On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 09/14/2017 10:43 AM, Daniel Neilson wrote: >>> Thank you for your thoughts, Hal. More information below... >>> >>>> On Sep 13, 2017, at 5:43 PM, Hal Finkel

Thank you for your thoughts, Hal. More information below... On Sep 13, 2017, at 5:43 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/13/2017 01:01 PM, Daniel Neilson via llvm-dev wrote: … snip For example, the following IR will produce different sets of IV users if either: i) The order of the PHI nodes in the %loop block are reordered; or ii) The

On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/14/2017 10:43 AM, Daniel Neilson wrote: Thank you for your thoughts, Hal. More information below... On Sep 13, 2017, at 5:43 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/13/2017 01:01 PM, Daniel Neilson via llvm-dev wrote: … snip For

My code to create an ExecutionEngine is segfaulting: std::string errStr; llvm::ExecutionEngine * ee = llvm::EngineBuilder( unique_ptr<llvm::Module>(module) ) .setErrorStr( &errStr ) //line 1618 .setEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Jingyue Wu" <jingyue at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, June 30, 2015 8:16:13 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > > Hi Adam, > > Jingyue is right. We need to keep

On Mon, Nov 18, 2013 at 11:06 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com> > wrote: >> >> On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: >> > Hi Bill, >> > >> > Thanks for the testing case. Most of the time is

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 *