[llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()

[Justin Holewinski]

On Thu, May 31, 2012 at 10:21 PM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:

> On Thu, May 31, 2012 at 8:06 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On May 31, 2012, at 2:39 PM, Justin Holewinski wrote:
>>
>> > The attached patch add the ability to programmatically re-direct
>> outs()/errs() to an arbitrary raw_ostream instance, maintaining the
>> raw_ostream instances in a stack structure so clients can push/pop streams
>> at will.  The stack is also maintained in thread-local storage, so
>> different threads can re-direct individually.  This allows for two use
>> cases:
>> >
>> > 1. Compilers can attach custom streams to outs()/errs() to intercept
>> output from LLVM without needing to play with STDOUT/STDERR.
>> > 2. Compilers can receive LLVM output from different threads
>> individually, instead of having all diagnostics dumped to a single stream.
>>
>> This isn't the right approach.  Nothing in the library part of the
>> compiler should be hard coding a stream to write to.  What are you trying
>> to accomplish?
>>
>
> There are a lot of places where warning/debug information is passed
> directly to errs().  For example, take the Linker class.  You can tell it
> to omit errors/warnings, but it would be preferable to let it emit the
> errors/warnings to some compiler-controlled stream for message triaging.
>
> For compilers that are (a) multi-threaded, or (b) invoked as part of an
> embedded library, writing any information from the core libraries directly
> to stderr is bad.  I want to be able to capture this output without messing
> with the process' stdout/stderr streams.
>
> This patch essentially prevents LLVM library code from having to hard-code
> streams for error/warning/diagnostic output.  Library code can just use
> outs()/errs() as they do now, but the compiler process/thread now has the
> ability to re-direct this output as it sees fit. If no such functionality
> is needed, the default behavior is to write to stdout/stderr as it does now.
>

Perhaps I'm just getting the wrong impression from the current LLVM code
base.  Take this snippet from LinkModules.cpp:

  if (!SrcM->getDataLayout().empty() && !DstM->getDataLayout().empty() &&
      SrcM->getDataLayout() != DstM->getDataLayout())
    errs() << "WARNING: Linking two modules of different data layouts!\n";
  if (!SrcM->getTargetTriple().empty() &&
      DstM->getTargetTriple() != SrcM->getTargetTriple()) {
    errs() << "WARNING: Linking two modules of different target triples: ";
    if (!SrcM->getModuleIdentifier().empty())
      errs() << SrcM->getModuleIdentifier() << ": ";
    errs() << "'" << SrcM->getTargetTriple() << "' and '"
           << DstM->getTargetTriple() << "'\n";
  }

Would I be correct in assuming that this is actually "bad" code since it's
a library function that writes directly to stderr?

Is the recommended approach to pass a stream to the constructor of any pass
or function that wants to emit output outside of debug mode?  My concern
with this approach is that the compiler would then need to know which
passes expect an output stream, and which do not.  The supplied patch
allows passes to output information without having to worry about where the
output is going, it is up to the compiler to specify where this output
goes.


>
>
>>
>> -Chris
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
>
> --
>
> Thanks,
>
> Justin Holewinski
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120601/57e9b328/attachment.html>