llvm dev - Nov 2012 - [LLVMdev] [llvm-commits] Flag to print vectorized loops

On Nov 26, 2012, at 3:46 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
> 
> In my opinion, what we really need is an interface that the frontend can
use to get information from the backend optimizers. Then the frontend can
display this information to users in an appropriate way.
I  agree. 
> Furthermore, this information should be structured (we already have a YAML
parser, so that might be a good choice),
YAML is a great way to serialize these messages, and pass them to IDEs, etc. 
But I think that we should start discussing the interfaces.
> and should probably directly take a Value *, BasicBlock *, Function *, etc.
so that the frontend can do the appropriate mapping for the user.
> 
+1 


Thanks,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121126/d311b6aa/attachment.html>

On Nov 26, 2012, at 6:00 PM, Nadav Rotem <nrotem at apple.com> wrote:
> 
> On Nov 26, 2012, at 3:46 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>> 
> 
>> In my opinion, what we really need is an interface that the frontend
can use to get information from the backend optimizers. Then the frontend can
display this information to users in an appropriate way.
> 
> I  agree. 
> 
>> Furthermore, this information should be structured (we already have a
YAML parser, so that might be a good choice),
> 
> YAML is a great way to serialize these messages, and pass them to IDEs,
etc.  But I think that we should start discussing the interfaces.
> 
>> and should probably directly take a Value *, BasicBlock *, Function *,
etc. so that the frontend can do the appropriate mapping for the user.
>> 
> 
> +1 
IMO, the right way to build this is something like
"InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and
more structured :).  The basic jist of it is that the backend can push messages
up, and the frontend can register its hooks to render them however it likes.  In
this case, I agree that clang "Notes" or some new
"informational" diagnostic is probably the right way to go.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121126/3c616564/attachment.html>

> IMO, the right way to build this is something like
> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully
better, and more
> structured :)
Hey Chris,

Did you catch my suggestion in reply to Hal, about maybe generalizing
Clang's diagnostics infrastructure up into LLVM? Your reply seems
along the same lines. It seems like a natural fit to reuse that rather
than make another one (and it would permit seamless integration).
Also, presumably LLD is going to be giving sweet diagnostics some day,
and this change would be analogous to the work that Michael Spencer
has been doing lifting and generalizing the option-parsing stuff from
Clang. What do you think about that approach?

-- Sean

On Mon, Nov 26, 2012 at 9:03 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Nov 26, 2012, at 6:00 PM, Nadav Rotem <nrotem at apple.com> wrote:
>
>
> On Nov 26, 2012, at 3:46 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>
>
> In my opinion, what we really need is an interface that the frontend can
use
> to get information from the backend optimizers. Then the frontend can
> display this information to users in an appropriate way.
>
>
> I  agree.
>
> Furthermore, this information should be structured (we already have a YAML
> parser, so that might be a good choice),
>
>
> YAML is a great way to serialize these messages, and pass them to IDEs,
etc.
> But I think that we should start discussing the interfaces.
>
> and should probably directly take a Value *, BasicBlock *, Function *, etc.
> so that the frontend can do the appropriate mapping for the user.
>
>
> +1
>
>
> IMO, the right way to build this is something like
> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully
better, and more
> structured :).  The basic jist of it is that the backend can push messages
> up, and the frontend can register its hooks to render them however it
likes.
> In this case, I agree that clang "Notes" or some new
"informational"
> diagnostic is probably the right way to go.
>
> -Chris
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>