> 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 >
Eli Friedman
2012-Nov-27 02:33 UTC
[LLVMdev] [llvm-commits] Flag to print vectorized loops
On Mon, Nov 26, 2012 at 6:26 PM, Sean Silva <silvas at purdue.edu> wrote:>> 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?clang's diagnostic code is inseparably tied to clang's SourceManager, which really only makes sense for code using clang's Lex library. It might make sense to have a simpler diagnostic printing library in LLVM even if clang can't use it. -Eli
On Mon, Nov 26, 2012 at 9:33 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> > clang's diagnostic code is inseparably tied to clang's SourceManager, > which really only makes sense for code using clang's Lex library.Bummer. -- Sean Silva
----- Original Message -----> From: "Eli Friedman" <eli.friedman at gmail.com> > To: "Sean Silva" <silvas at purdue.edu> > Cc: llvm-commits at cs.uiuc.edu, "Sebastian Pop" <spop at codeaurora.org>, llvmdev at cs.uiuc.edu > Sent: Monday, November 26, 2012 8:33:51 PM > Subject: Re: [llvm-commits] [LLVMdev] Flag to print vectorized loops > > On Mon, Nov 26, 2012 at 6:26 PM, Sean Silva <silvas at purdue.edu> > wrote: > >> 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? > > clang's diagnostic code is inseparably tied to clang's SourceManager, > which really only makes sense for code using clang's Lex library. It > might make sense to have a simpler diagnostic printing library in > LLVM > even if clang can't use it.Printing notices is one useful way this information can be used, but not the only method. This information can also be used in IDEs for hover-over popups (and similar UI widgets). One generic capability that clang should eventually provide is the generation of 'listing' files. These are copies of the source code where each line is annotated with information on what optimizations were performed and/or hints on why some common or requested optimization was not performed. -Hal> > -Eli > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Seemingly Similar Threads
- [LLVMdev] [llvm-commits] Flag to print vectorized loops
- [LLVMdev] [llvm-commits] Flag to print vectorized loops
- [LLVMdev] [llvm-commits] Flag to print vectorized loops
- [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM
- [LLVMdev] [cfe-dev] LLVM & Clang file management