Displaying 6 results from an estimated 6 matches for "emitdiagnostic".
2012 Jun 04
2
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
...and
> figured it wasn't the right tool for the job! :)
Inline asm is the only place where we have a way of mapping form LLVM
IR to frontend source locations at the moment.
> As Hal points out, this only covers errors at the moment. Is there any
> resistance to changing emitError to emitDiagnostic and having a
> SourceMgr::DiagKind argument? This should cover the case where a pass wants
> to emit a warning or info message that is not part to DEBUG.
>
> With LLVMContext::emitDiagnostic, this should cover my use case.
I'm not exactly opposed, but what is your use case?
-Eli
2012 Jun 04
0
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
...right over the emitError methods
the last time I read through this stuff because I saw "InlineAsm"
everywhere and figured it wasn't the right tool for the job! :)
2. As Hal points out, this only covers errors at the moment. Is there
any resistance to changing emitError to emitDiagnostic and having a
SourceMgr::DiagKind argument? This should cover the case where a pass
wants to emit a warning or info message that is not part to DEBUG.
With LLVMContext::emitDiagnostic, this should cover my use case.
> -Hal
>
> >
> > -Chris
> >
> > ___________...
2012 Jun 03
2
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
On Sun, 03 Jun 2012 12:12:06 -0700
Chris Lattner <clattner at apple.com> wrote:
>
> On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote:
>
> > If I may add my two cents:
> >
> > I am planning to use LLVM as the backend for a compiler I am
> > working on. And I wholeheartedly agree with Justin that it is a
> > problem, if LLVM is allowed to freely
2012 Jun 04
0
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
...>
But is that strictly required? Lacking the right annotations, we could
print IR information like function name, basic block name, global variable
name, etc.
>
> > As Hal points out, this only covers errors at the moment. Is there any
> > resistance to changing emitError to emitDiagnostic and having a
> > SourceMgr::DiagKind argument? This should cover the case where a pass
> wants
> > to emit a warning or info message that is not part to DEBUG.
> >
> > With LLVMContext::emitDiagnostic, this should cover my use case.
>
> I'm not exactly opposed,...
2012 Jun 04
2
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
...t; name, etc.
Basic block names are useless to the user. Function/global names are
not really ideal, but could be reasonable depending on what you're
doing.
>> > As Hal points out, this only covers errors at the moment. Is there any
>> > resistance to changing emitError to emitDiagnostic and having a
>> > SourceMgr::DiagKind argument? This should cover the case where a pass
>> > wants
>> > to emit a warning or info message that is not part to DEBUG.
>> >
>> > With LLVMContext::emitDiagnostic, this should cover my use case.
>>
>...
2012 Jun 05
0
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
> 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