similar to: [LLVMdev] the definitions of internal functions and external functions

Hi, I have a llvm-pass in hand written by other people. There are following statements that I couldn't understand: -------------------------------program---------------------------------------------------- ... if (isa<CallInst>(inst) || isa<InvokeInst>(inst)) { const CallSite cs(inst); if (cs.getCalledFunction() == NULL) return dealAtIndirectCall(cs); else

Hello, I found a function call Function::isDeclaration() in llvm 2.5 (I know that's ancient...), which is useful to me, but I can't find it in the later version 3.3, nor the latest 3.7.....Therefore, is there an alternative way to check whether the function is just a declaration or a definition ? PS: I read the source code of llvm 2.5, and found isDeclaration is simply to check if the

On Tuesday 04 August 2009 18:24, Chris Lattner wrote: > The big issue is things like this: > > DOUT << foo.getName() << "\n"; > > When -debug is disable and even when assertions are turned off, > foo.getName() is still called. When you use: Yep, that's a problem. > DEBUG(errs() << foo.getName() << "\n"); > > When

On Tuesday 04 August 2009 10:46, Chris Lattner wrote: > On Aug 4, 2009, at 8:29 AM, Aaron Gray wrote: > > How do output hex in DOUT's ? > > Please don't use DOUT, please use: > > DEBUG(errs() << stuff); > > instead. I've got some more DOUT-involving patches in the queue. Is this a general design choice that's been made? If so I can change the

On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > >> A debug or release build? >> >> -bw > > Both, actually. Weird. I see a potential problem, though. The code is like this: void dumpToDOUT(SparseBitVector<> *bitmap) { dump(*bitmap, DOUT); } where dump expects an llvm::OStream& for the

Andreas Neustifter wrote: > Hi, > > I try to create a array that has a nonzero initialiser: > > What i do is, first create the array type. > > > const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges); > > Then create some constant values for the initializer. > > > std::vector<Constant*> Initializer; Initializer.reserve(NumEdges); > >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Andreas Neustifter wrote: > Daniel Dunbar wrote: >> Thanks, applied as r78247. Next? :) > > Oh my, first he is lagging and now it's all a hurry :-) > > Okay, here comes the next one. > > I'm taking a short vacation next week so I will try to prepare 1 or 2 of > the next patches so that you can work on them

On Dec 11, 2009, at 9:03 AM, David Greene wrote: >> >> If you're asking if a new dbgs() might be useful, "yes if specified well". >> If you're asking if you can convert everything to using it, "no". > > I'm not sure what you mean here. It's not ok to convert code under DEBUG() or > #ifndef NDEBUG to use dbgs()? Right. > Then

On Friday 11 December 2009 11:35, Chris Lattner wrote: = > > I'm not sure what you mean here. It's not ok to convert code under > > DEBUG() or #ifndef NDEBUG to use dbgs()? > > Right. > > > Then what's the point of providing it? > > I don't know what dbgs does, so I don't know! dbgs() will be a circular-buffering raw_ostream, meaning it saves

TL;DR - when linking from a lazily loaded module and using Linker::LinkOnlyNeeded, bodies of used functions aren't being copied during linking. Previously on one of our products, we would lazily load our runtime module (around 9000 functions), and link some user module into this (which is in all practical use cases much smaller). Then, post linking, we have a pass that runs over the

On Monday 24 September 2007 17:23, Bill Wendling wrote: > Weird. I see a potential problem, though. The code is like this: > > void dumpToDOUT(SparseBitVector<> *bitmap) { > dump(*bitmap, DOUT); > } > > where dump expects an llvm::OStream& for the second argument. > However, when NDEBUG is #defined, DOUT is "llvm::OStream(0)", so it > can't be

+cc Artem, who added the LinkOnlyNeeded flag. On Wed, Apr 20, 2016 at 9:18 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Neil, > > On Apr 20, 2016, at 5:20 AM, Neil Henning via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > TL;DR - when linking from a lazily loaded module and using > Linker::LinkOnlyNeeded, bodies of used functions

On Aug 4, 2009, at 8:29 AM, Aaron Gray wrote: > How do output hex in DOUT's ? Please don't use DOUT, please use: DEBUG(errs() << stuff); instead. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090804/cda5fe94/attachment.html>

Hello, David > What replaced the old DOUT? DEBUG(errs() << foo); The reason is quite simple - DOUT in release mode was just /dev/null, but the functions sending data to it were still called. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

What replaced the old DOUT? I'm working on sending debug code upstream and one of the things I want to add is circular buffering for debug output. This is a real help when processing large files. So I need a stream that can act differently than errs(). Should I just create one? -Dave

>>How do output hex in DOUT's ? >Please don't use DOUT, please use: > > DEBUG(errs() << stuff); > >instead. Okay, I will modify my code. But how do I do hexadecimal output ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090804/6614cf39/attachment.html>

On Aug 4, 2009, at 4:03 PM, David Greene wrote: > On Tuesday 04 August 2009 17:52, Chris Lattner wrote: > >> I'd prefer for it to be eliminated, but it is currently used widely. >> If your patches don't make it substantially worse, I won't have a >> problem with them. Bonus points for removing DOUTs though :) > > Ok, this is good to know. With some of

On Thursday 10 December 2009 16:30, Anton Korobeynikov wrote: > Hello, David > > > What replaced the old DOUT? > > DEBUG(errs() << foo); > > The reason is quite simple - DOUT in release mode was just /dev/null, > but the functions sending data to it were still called. errs() is no good. I would want to keep errs() printing things out immediately. I need

On 9/24/07, Bill Wendling <isanbard at gmail.com> wrote: > On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > > > > On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > > > >> A debug or release build? > >> > >> -bw > > > > Both, actually. > > Weird. I see a potential problem, though. The code is like this: > >

On 9/25/07, Daniel Berlin <dberlin at dberlin.org> wrote: > On 9/24/07, Bill Wendling <isanbard at gmail.com> wrote: > > On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > > > Weird. I see a potential problem, though. The code is like this: > > > > void dumpToDOUT(SparseBitVector<> *bitmap) { > > dump(*bitmap, DOUT); > > } >