[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
Justin Holewinski
justin.holewinski at gmail.com
Mon Jun 4 21:49:51 PDT 2012
On Mon, Jun 4, 2012 at 6:04 PM, Caldarale, Charles R <
Chuck.Caldarale at unisys.com> wrote:
> > From: Eli Friedman [mailto:eli.friedman at gmail.com]
> > Subject: Re: [llvm-commits] [LLVMdev] [PATCH] Allow per-thread
> re-direction of outs()/errs()
>
> > Basic block names are useless to the user.
>
> I think that depends on the user. If clang is your entry point into the
> game, then yes, basic block names and many other things going on with the
> IR are probably meaningless. However, our starting point is
> llvm::IRBuilder, so having the basic block names and individual
> instructions available on live, running systems is critical to problem
> analysis. Function granularity is by no means sufficient.
>
The emitDiagnostic interface can contain an optional Value* parameter,
which the handler can use to reconstruct source level information, using
srcloc, debug metadata, etc.. If the originating pass detects an error in
a function prototype, it can pass the function pointer. If an optimizer
wants to flag a specific instruction, it can pass that instruction as the
Value* parameter. So it would be up to the pass to determine what level of
granularity is sufficient for the particular error/warning/info message,
and we can have generic handler fragments that know how to print textual
representations of different Value types.
How does this sound?
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
--
Thanks,
Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120604/d9fc2fba/attachment.html>
More information about the llvm-dev
mailing list