[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