<div class="gmail_quote">On Fri, Jun 1, 2012 at 10:17 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><br><div><div>On Jun 1, 2012, at 7:41 PM, Justin Holewinski wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>><br>> Unfortunately, the use of outs() and (especially) errs() is rampant - a simple grep of the 3.1 source tree shows about 1,500 instances.  One of the first things we had to implement in order to make LLVM usable is something very similar to what Justin has proposed.  Centralizing control of the output in outs()/errs() would seem to be an ideal way to let users of LLVM as a library customize it as they see fit without requiring massive source changes.<br>

<br></div>Virtually all of those are in DEBUG statements or in llvm/tools.  Neither are relevant to the discussion.<br></blockquote><div><br></div><div>In a way, they are.  What if I want a debug trace in a multi-threaded context?  Right now, all threads would just spew to the same stream and the result would be unreadable.  If you allow threads to setup their own outs() and errs() streams (transparently to the rest of LLVM), you can intercept these as you see fit, perhaps dumping each to a separate file.  I acknowledge that you could also enforce single-threaded execution for debug runs, but what if you are in the context of a library with no valid stdout/stderr buffers?</div>

<div><br></div></span></blockquote><br></div></div><div>This doesn't make any sense.  There is very little sense in trying to use DEBUG (which gets compiled out of optimized builds) in a multithreaded context.  Polluting the purity of outs() and errs() because of this sort of use case doesn't make any sense to me.</div>

<div><br></div><div>outs() and errs() are useful independent of how LLVM happens to use them.  The extensions that you are proposing doesn't make any sense give nthe design of raw_ostream.</div></div></blockquote><div>

<br></div><div>Is the problem more that outs() and errs() should always point to valid stdout/stderr streams, regardless of how the hosting compiler is implemented?</div><div><br></div><div>If so, how do you feel about introducing a new global stream, logs()?  This could replace all uses of outs()/errs() in the LLVM libraries, and default to errs().  Existing command-line tools could just use this default, but compilers that are hosted inside of libraries or other non-command line scenarios can attach a custom stream to logs() that captures all LLVM output, including DEBUG and any legitimate pass output.  Command-line tools can continue to use outs()/errs() just as they do now.  Nothing would really change in the way LLVM operates by default.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>-Chris</div>
<div><br></div></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>