llvm dev - Aug 2009 - [LLVMdev] std::cout << *MyModule does not work anymore

It seems that support for dumping text representation of LLVM objects to
standard channels and C++ output streams was removed. My guess is that
now we must use errs() instead of std::cerr, llvm::raw_fd_ostream
instead of std::ofstream, etc.

The changes are not trivial, as for instance llvm::raw_fd_ostream
without flags fails if the file exists, but std::ofstream does not. The
changes include using new names for flags that already exist on the
standard namespace (F_Force instead of O_TRUNC, etc).

Is all this an unintended change or an intentional one, and if the
later, could you direct me to something that explains what we gain on
exchange of this restriction?

-- 
Óscar

On Mon, Aug 24, 2009 at 5:40 PM, Óscar Fuentes<ofv at wanadoo.es>
wrote:
> It seems that support for dumping text representation of LLVM objects to
> standard channels and C++ output streams was removed. My guess is that
> now we must use errs() instead of std::cerr, llvm::raw_fd_ostream
> instead of std::ofstream, etc.
Correct. std::ostream has been purged from LLVM; the only exception is
the raw_os_ostream class, which can be used to adapt an std::ostream
for use with raw_ostream. This should be enough for clients which want
to keep using std::ostream.
> The changes are not trivial, as for instance llvm::raw_fd_ostream
> without flags fails if the file exists, but std::ofstream does not. The
> changes include using new names for flags that already exist on the
> standard namespace (F_Force instead of O_TRUNC, etc).
I believe that Dan plans to fix the "force by default" issue, at
least.
> Is all this an unintended change or an intentional one, and if the
> later, could you direct me to something that explains what we gain on
> exchange of this restriction?
Intentional. std::ostream has long been deprecated in LLVM, each
release has increased the degree of deprecation. The coding standards
document has various bits of information on this
http://llvm.org/docs/CodingStandards.html.

Among other things, you gain performance. raw_ostream is considerably
faster than std::ostream. This is the performance difference on the my
synthetic raw_ostream benchmark:
- raw_fd_ostream (outs()) -
--
name	  avg  	  min  	  med  	  max  	   SD  	 total
user	 1.0002	 0.9990	 0.9992	 1.0024	 0.0015	 3.0006
 sys	 0.0089	 0.0074	 0.0079	 0.0114	 0.0018	 0.0268
wall	 1.0368	 1.0137	 1.0185	 1.0782	 0.0294	 3.1104
--

- std::ostream (cout) -
--
name	  avg  	  min  	  med  	  max  	   SD  	 total
user	 6.8846	 6.8807	 6.8853	 6.8878	 0.0029	20.6537
 sys	 0.0384	 0.0377	 0.0352	 0.0423	 0.0029	 0.1152
wall	 6.9852	 6.9685	 6.9756	 7.0115	 0.0188	20.9555
--

 - Daniel

Daniel Dunbar <daniel at zuster.org> writes:

[snip]
>> Is all this an unintended change or an intentional one, and if the
>> later, could you direct me to something that explains what we gain on
>> exchange of this restriction?
>
> Intentional. std::ostream has long been deprecated in LLVM, each
> release has increased the degree of deprecation. The coding standards
> document has various bits of information on this
> http://llvm.org/docs/CodingStandards.html.
>
> Among other things, you gain performance. raw_ostream is considerably
> faster than std::ostream. This is the performance difference on the my
> synthetic raw_ostream benchmark:
[snip]

First of all, thanks to Daniel for the answer to my questions.

To the LLVM library designers:

Okay, so your wheel is lighter and faster. Sometimes this is a good
justification for reinventing the wheel when everybody is eager to throw
away the old wheels and use yours instead :-). However, when LLVM is
just another library on an application (something that I hope often
happens thanks to the great JIT it provides) having to learn the quirks
and kinks of something that pretends to replace a common functionality
of the language's standard library *plus* integrating it into the
existing code can be a real burden. Maybe the LLVM ostream replacement
knows how to handle LLVM objects, but it certainly knows nothing about
how to deal with user's objects and this may create quite a bit of work
when you have a mixed series of output statements with both kinds of
objects.

Maybe there was a solution that was okay for those concerned with fast &
lightweight executables and for the others who care most about
consistency and code stability. I would appreciate if this changes are
discussed before applying them on the future (maybe I missed the
thread), flagging the subject with something that indicates that the
outcome of the discussion may break existing code.

Thanks for your mostly excellent work on LLVM's design and policy-making
;-)

-- 
Óscar

Óscar Fuentes wrote:
> The changes are not trivial, as for instance llvm::raw_fd_ostream
> without flags fails if the file exists, but std::ofstream does not. The
> changes include using new names for flags that already exist on the
> standard namespace (F_Force instead of O_TRUNC, etc).
Also, each of LLVM <=2.5, 2.6 and 2.7(svn) provide their own,
incompatible llvm::raw_fd_ostream constructors. This makes it
unneccessarily hard to support different LLVM versions in a frontend.

I understand why the llvm::raw_fd_ostream interface was changed, but it
would have been nice if the old constructors were kept and implemented
in terms of the new ones. That's completely trivial in this case and
shouldn't cause any harm in existing applications. For many applications
other than LLVM itself, the basic LLVM <=2.5 interface which just
overwrites existing files is all that's ever needed.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

On Aug 25, 2009, at 1:04 AM, Albert Graef wrote:
> . For many applications
> other than LLVM itself, the basic LLVM <=2.5 interface which just
> overwrites existing files is all that's ever needed.
On LLVM trunk, raw_fd_ostream is now back to overwriting files by
default, as it is the unanimous preference among in-tree users (and
out-of-tree users that I'm aware of).

Dan