Hi all, With the newest patches to LLVM, there should be no reason for having "#include <iostream>" in any library source code file, except for lib/ Support/Streams.cpp. Please use the following instead: OLD NEW --- --- std::ostream llvm::OStream std::istream llvm::IStream std::cerr llvm::cerr std::cerr llvm::cout std::cin llvm::cin DEBUG(std::cerr DOUT If you have something like this: void print(std::ostream& O); You can pass the LLVM streams in like this: print(*cerr.stream()); Or you can change the print() method to take an llvm ostream: void print(llvm::OStream& O); print(cerr); -bw
On Thu, 7 Dec 2006, Bill Wendling wrote:> With the newest patches to LLVM, there should be no reason for having > "#include <iostream>" in any library source code file, except for lib/ > Support/Streams.cpp. Please use the following instead: > > OLD NEW > --- --- > std::ostream llvm::OStream > std::istream llvm::IStream > std::cerr llvm::cerr > std::cerr llvm::cout > std::cin llvm::cinNice! Can you add this to the coding standard guide when you get a chance? Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/
Bill Wendling wrote:> Hi all, > > With the newest patches to LLVM, there should be no reason for having > "#include <iostream>" in any library source code file, except for lib/ > Support/Streams.cpp. Please use the following instead: > > OLD NEW > --- --- > std::ostream llvm::OStream > std::istream llvm::IStream > std::cerr llvm::cerr > std::cerr llvm::cout > std::cin llvm::cin > DEBUG(std::cerr DOUT > > If you have something like this: > > void print(std::ostream& O); > > You can pass the LLVM streams in like this: > > print(*cerr.stream()); > > Or you can change the print() method to take an llvm ostream: > > void print(llvm::OStream& O); > > print(cerr);And what is the actual measured effect on compile time and run time? Just curious, Volodya
On Dec 7, 2006, at 10:57 PM, Vladimir Prus wrote:> And what is the actual measured effect on compile time and run time? > > Just curious,I haven't done measurements yet. I'll try to do that soon. I have some more clean-up to do on the LLVM streams first. -bw
On Dec 7, 2006, at 5:35 PM, Chris Lattner wrote:> On Thu, 7 Dec 2006, Bill Wendling wrote: > >> With the newest patches to LLVM, there should be no reason for having >> "#include <iostream>" in any library source code file, except for >> lib/ >> Support/Streams.cpp. Please use the following instead: >> >> OLD NEW >> --- --- >> std::ostream llvm::OStream >> std::istream llvm::IStream >> std::cerr llvm::cerr >> std::cerr llvm::cout >> std::cin llvm::cin > > Nice! Can you add this to the coding standard guide when you get a > chance? >Okay. :-) -bw
On Fri, 8 Dec 2006, Vladimir Prus wrote:> And what is the actual measured effect on compile time and run time?The main impact of eliminating the #include of <iostream> is that it eliminates a static ctor from each .o file that #includes it. For something like llvm-gcc4, this will marginally reduce the startup time of the app, though probably not significantly (it may not even be measurable). The primary reason for doing this is to support clients using LLVM as libraries as part of larger systems. In particular, we statically link LLVM into some dynamic libraries. Even if LLVM isn't used, the static ctors are run whenever an app starts up that uses the dynamic library. There are two problems with this: 1) The time to run the static ctors impacts startup time of applications, a critical time for gui apps. 2) the static ctors cause the app to pull many extra pages of memory off the disk: both the code for the static ctors in each .o file and the small amount of data that gets touched. In addition, touched/dirty pages put more pressure on the VM system on low-memory machines. #2 is the big killer, and it's a reason we're eliminating static ctors in general. Soon I will be landing a patch to the Statistic class that eliminates its static ctor, which will eliminate another large contributor to the problem. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Bill Wendling wrote: It seems that when compiling Debug versions of LLVM, we use stream manipulators (like std::hex) on the new LLVM streams, and doing so causes a compiler error when compiling LLVM with GCC 3.4.0. I commited a fix to work around the problem, but it seems to me it would be better if LLVM streams could support common stream manipulators. First, has anyone else experienced the compiler error I ran into? And second, is there any easy way to get LLVM streams to work with standard stream manipulators? -- John T.> Hi all, > > With the newest patches to LLVM, there should be no reason for having > "#include <iostream>" in any library source code file, except for lib/ > Support/Streams.cpp. Please use the following instead: > > OLD NEW > --- --- > std::ostream llvm::OStream > std::istream llvm::IStream > std::cerr llvm::cerr > std::cerr llvm::cout > std::cin llvm::cin > DEBUG(std::cerr DOUT > > If you have something like this: > > void print(std::ostream& O); > > You can pass the LLVM streams in like this: > > print(*cerr.stream()); > > Or you can change the print() method to take an llvm ostream: > > void print(llvm::OStream& O); > > print(cerr); > > -bw > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Dec 11, 2006, at 11:18 AM, John Criswell wrote:> Bill Wendling wrote: > > It seems that when compiling Debug versions of LLVM, we use stream > manipulators (like std::hex) on the new LLVM streams, and doing so > causes a compiler error when compiling LLVM with GCC 3.4.0. > > I commited a fix to work around the problem, but it seems to me it > would > be better if LLVM streams could support common stream manipulators. > > First, has anyone else experienced the compiler error I ran into? And > second, is there any easy way to get LLVM streams to work with > standard > stream manipulators? >Hi John, I had a similar problem with things like "std::flush" and "std::endl". I believe I can fix the problem easily. Could you file a bug and assign it to me? I'll work on it. I think I can get it fixed without too much trouble. (Hopefully not famous last words.) Could you place in the bug report the name of the source file you put the fix in? Thanks! -bw