search for: value_use_iterator

...ospectively? > > I saw the slides, it looks very interesting. Have you actually measured any > memory wins from this? Hi Chris, there are no memory savings, Use has still 3 pointers (the 4->3 reduction happened back in 2008). What should be faster with the new algorithm are the "value_use_iterator::operator->" operators (i.e. finding all Users of a Value). Cheers, Gabor > > -Chris >

...Concept = __g nu_cxx::_EqualOpConcept<llvm::BasicBlock, llvm::BasicBlock*>]' c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_algo.h: 3810: instan tiated from '_IIter std::find(_IIter, _IIter, const _Tp&) [with _IIter = llvm::P redIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> >, _Tp = llvm ::BasicBlock*]' BasicBlock.cpp:180: instantiated from here c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ boost_concept_check.h:296 : error: no match for 'operator==' in '((__gnu_cxx::_EqualOpConcept<llvm::BasicB lock, llvm::Basi...

...object. It's owned by a > User, but isn't a subclass of one. To match the first loop, you either > need to call Value::user_begin instead of use_begin, or do the cast on > "ui->getUser()". > I think this is incorrect since the use_iterator is defined as: `typedef value_use_iterator<User> use_iterator;` and indeed `ui->getUser();` is not a callable function on a User. What am I missing? -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140809/ed8317a4/attachment.html>

...ept = __gnu_cxx::_EqualOpConcept<llvm::BasicBlock, llvm::BasicBlock*>]’ /usr/lib/gcc/i386-pc-solaris2.11/4.3.2/../../../../include/c++/4.3.2/bits/stl_algo.h:3810: instantiated from ‘_IIter std::find(_IIter, _IIter, const _Tp&) [with _IIter = llvm::PredIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> >, _Tp = llvm::BasicBlock*]’ BasicBlock.cpp:181: instantiated from here /usr/lib/gcc/i386-pc-solaris2.11/4.3.2/../../../../include/c++/4.3.2/bits/boost_concept_check.h:296: error: no match for ‘operator==’ in ‘((__gnu_cxx::_EqualOpConcept<llvm::BasicBlock, llvm::BasicBlock...

...ualOpConcept<llvm::BasicBlock, llvm::BasicBlock*>]' > c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_algo.h: > 3810: instan > tiated from '_IIter std::find(_IIter, _IIter, const _Tp&) [with > _IIter = llvm::P > redIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> > >, _Tp = llvm > ::BasicBlock*]' > BasicBlock.cpp:180: instantiated from here > c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ > boost_concept_check.h:296 > : error: no match for 'operator==' in > '((__gnu_cxx::_EqualOpConce...

...:getUser() > 2) Use::get/set due to tagging. > > The former is seldom called: > > $ find lib -name "*.cpp" | xargs grep "getUser(" | wc -l > 41 The majority of those aren't actually Use::getUser, but on the other hand this grep misses all the users of value_use_iterator::operator*, which is much more popular. Unfortunately, overloaded operators are not the easiest to grep for ;-). > The second is counterbalanced with a faster access to the Use object > in most cases: > With exception of PHINode and SwitchInst, the getOperand() function > (if called o...

On Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with

Why is the first for loop not equivalent to the second? Thanks, Rob =========================== for (GlobalVariable **i = Globals.begin(), **e = Globals.end(); i != e; ++i) { GlobalVariable *GV = *i; Constant *GEP = ConstantExpr::getGetElementPtr(...); GV->replaceAllUsesWith(GEP); } =========================== for (GlobalVariable **i = Globals.begin(), **e = Globals.end(); i != e;

> I think this is incorrect since the use_iterator is defined as: > > `typedef value_use_iterator<User> use_iterator;` > > and indeed `ui->getUser();` is not a callable function on a User. What am I > missing? Ah, looks like this has changed this year. What I said applies to trunk; you may be right there about 3.4 or earlier (looks plausible from the key commit). Another pro...

...lvm::BasicBlock, llvm::BasicBlock*>]' >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_algo.h: >> 3810: instan >> tiated from '_IIter std::find(_IIter, _IIter, const _Tp&) [with >> _IIter = llvm::P >> redIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> >>> , _Tp = llvm >> ::BasicBlock*]' >> BasicBlock.cpp:180: instantiated from here >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >> boost_concept_check.h:296 >> : error: no match for 'operator==' in >> '((_...

Hi devs, after my intentionally "playful" EuroLLVM presentation (*) I think it would be time to get serious about merging to ToT. But we should probably find out whether an optimized algorithm is desired at all. So I'd solicit comments from the code owners (Use.{h,cpp}) and anybody who is interested. For closer scrutiny, the code is here:

...::BasicBlock, llvm::BasicBlock*>]' >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_algo.h: >> 3810: instan >> tiated from '_IIter std::find(_IIter, _IIter, const _Tp&) [with >> _IIter = llvm::P >> redIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> >> >>> , _Tp = llvm >>> >> ::BasicBlock*]' >> BasicBlock.cpp:180: instantiated from here >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >> boost_concept_check.h:296 >> : error: no match for '...

...oncept = __gnu_cxx::_EqualOpConcept<llvm::BasicBlock, llvm::BasicBlock*>]' d:\msys\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/stl_algo.h:3810: instantiated from '_IIter std::find(_IIter, _IIter, const _Tp&) [with _IIter = llvm::PredIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> >, _Tp = llvm::BasicBlock*]' BasicBlock.cpp:180: instantiated from here d:\msys\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/boost_concept_check.h:296: error: no match for 'operator==' in '((__gnu_cxx::_EqualOpConcept<llvm::BasicBlock, llvm::B...

...m::BasicBlock*>]' >>> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_algo.h: >>> 3810: instan >>> tiated from '_IIter std::find(_IIter, _IIter, const _Tp&) [with >>> _IIter = llvm::P >>> redIterator<llvm::BasicBlock, llvm::value_use_iterator<llvm::User> >>> >>>> , _Tp = llvm >>>> >>> ::BasicBlock*]' >>> BasicBlock.cpp:180: instantiated from here >>> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >>> boost_concept_check.h:296 >>> : error:...

Not that I sympathize with the OP's manners but... Bill Wendling <isanbard at gmail.com> writes: > On May 10, 2008, at 7:55 PM, kr512 wrote: > >> See how gcc is invoked to generate the final executable >> file. This means LLVM is an incomplete backend, >> unfortunately. >> > That's only a convenience. GCC generates assembly code too and calls