#include <iostream>

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

Nice! Can you add this to the coding standard guide when you get a chance?

Thanks,

-Chris

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

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

Okay. :slight_smile:

-bw

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

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 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