Hi, I would like to start a discussion about error/warning reporting in LLVM and how we can extend the current mechanism to take advantage of clang capabilities. ** Motivation ** Currently LLVM provides a way to report error either directly (print to stderr) or by using a user defined error handler. For instance, in inline asm parsing, we can specify the diagnostic handler to report the errors in clang. The basic idea would be to be able to do that for warnings too (and for other kind of errors?). A motivating example can be found with the following link where we want LLVM to be able to warn on the stack size to help developing kernels: http://llvm.org/bugs/show_bug.cgi?id=4072 By adding this capability, we would be able to have access to all the nice features clang provides with warnings: - Promote it to an error. - Ignore it. ** Challenge ** To be able to take advantage of clang framework for warning/error reporting, warnings have to be associated with warning groups. Thus, we need a way for the backend to specify a front-end warning type. The challenge is, AFAICT (which is not much, I admit), that front-end warning types are statically handled using tablegen representation. ** Advices Needed ** 1. Decide whether or not we want such capabilities (if we do not we may just add sporadically the support for a new warning/group of warning/error). 2. Come up with a plan to implement that (assuming we want it). Thanks for the feedbacks. Cheers, -Quentin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130716/b1d45d47/attachment.html>
On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote:> Hi, > > I would like to start a discussion about error/warning reporting in LLVM and > how we can extend the current mechanism to take advantage of clang > capabilities. > > > ** Motivation ** > > Currently LLVM provides a way to report error either directly (print to > stderr) or by using a user defined error handler. For instance, in inline > asm parsing, we can specify the diagnostic handler to report the errors in > clang. > > The basic idea would be to be able to do that for warnings too (and for > other kind of errors?). > A motivating example can be found with the following link where we want LLVM > to be able to warn on the stack size to help developing kernels: > http://llvm.org/bugs/show_bug.cgi?id=4072 > > By adding this capability, we would be able to have access to all the nice > features clang provides with warnings: > - Promote it to an error. > - Ignore it. > > > ** Challenge ** > > To be able to take advantage of clang framework for warning/error reporting, > warnings have to be associated with warning groups. > Thus, we need a way for the backend to specify a front-end warning type. > > The challenge is, AFAICT (which is not much, I admit), that front-end > warning types are statically handled using tablegen representation. > > > ** Advices Needed ** > > 1. Decide whether or not we want such capabilities (if we do not we may just > add sporadically the support for a new warning/group of warning/error). > 2. Come up with a plan to implement that (assuming we want it).The frontend should be presenting warnings, not the backend; adding a hook which provides the appropriate information shouldn't be too hard. Warnings coming out of the backend are very difficult to design well, so I don't expect we will add many. Also, keep in mind that the information coming out of the backend could be used in other ways; it might not make sense for the backend to decide that some piece of information should be presented as a warning. (Consider, for example, IDE integration to provide additional information about functions and loops on demand.) -Eli On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote:> Hi, > > I would like to start a discussion about error/warning reporting in LLVM and > how we can extend the current mechanism to take advantage of clang > capabilities. > > > ** Motivation ** > > Currently LLVM provides a way to report error either directly (print to > stderr) or by using a user defined error handler. For instance, in inline > asm parsing, we can specify the diagnostic handler to report the errors in > clang. > > The basic idea would be to be able to do that for warnings too (and for > other kind of errors?). > A motivating example can be found with the following link where we want LLVM > to be able to warn on the stack size to help developing kernels: > http://llvm.org/bugs/show_bug.cgi?id=4072 > > By adding this capability, we would be able to have access to all the nice > features clang provides with warnings: > - Promote it to an error. > - Ignore it. > > > ** Challenge ** > > To be able to take advantage of clang framework for warning/error reporting, > warnings have to be associated with warning groups. > Thus, we need a way for the backend to specify a front-end warning type. > > The challenge is, AFAICT (which is not much, I admit), that front-end > warning types are statically handled using tablegen representation. > > > ** Advices Needed ** > > 1. Decide whether or not we want such capabilities (if we do not we may just > add sporadically the support for a new warning/group of warning/error). > 2. Come up with a plan to implement that (assuming we want it). > > > Thanks for the feedbacks. > > Cheers, > > -Quentin > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Tue, Jul 16, 2013 at 5:51 PM, Eli Friedman <eli.friedman at gmail.com>wrote:> > 1. Decide whether or not we want such capabilities (if we do not we may > just > > add sporadically the support for a new warning/group of warning/error). > > 2. Come up with a plan to implement that (assuming we want it). > > The frontend should be presenting warnings, not the backend; adding a > hook which provides the appropriate information shouldn't be too hard. > Warnings coming out of the backend are very difficult to design well, > so I don't expect we will add many. Also, keep in mind that the > information coming out of the backend could be used in other ways; it > might not make sense for the backend to decide that some piece of > information should be presented as a warning. (Consider, for example, > IDE integration to provide additional information about functions and > loops on demand.) > > -EliI really like this design, where essentially the frontend can query the backend for very simple information using a nice API, and then emit the warning itself. I'm happy for the warning to be in the CodeGen layer of the frontend, and only be reachable when generating code for that function body. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130716/834d697d/attachment.html>
On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com>wrote:> > The challenge is, AFAICT (which is not much, I admit), that front-end > warning types are statically handled using tablegen representation. > >They can also be added dynamically if necessary. See DiagnosticsEngine::getCustomDiagID -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130716/b687351f/attachment.html>
On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote: >> ** Advices Needed ** >> >> 1. Decide whether or not we want such capabilities (if we do not we may just >> add sporadically the support for a new warning/group of warning/error). >> 2. Come up with a plan to implement that (assuming we want it). > > The frontend should be presenting warnings, not the backend; adding a > hook which provides the appropriate information shouldn't be too hard. > Warnings coming out of the backend are very difficult to design well, > so I don't expect we will add many. Also, keep in mind that the > information coming out of the backend could be used in other ways; it > might not make sense for the backend to decide that some piece of > information should be presented as a warning. (Consider, for example, > IDE integration to provide additional information about functions and > loops on demand.)I think we definitely need this. In fact, I tried adding something simple earlier this year but gave up when I realized that the task was bigger than I expected. We already have a hook for diagnostics that can be easily extended to handle warnings as well as errors (which is what I tried earlier), but the problem is that it is hardwired for inline assembly errors. To do this right, new warnings really need to be associated with warning groups so that can be controlled from the front-end. I agree with Eli that there probably won’t be too many of these. Adding a few new entries to clang’s diagnostic .td files would be fine, except that the backend doesn’t see those. It seems like we will need something in llvm that defines a set of “backend diagnostics”, along with a table in the frontend to correlate those with the corresponding clang diagnostics. That seems awkward at best but maybe it’s tolerable as long as there aren’t many of them. —Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130716/b5a97b1e/attachment.html>
On 7/16/2013 10:38 PM, Sean Silva wrote:> > > > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com > <mailto:qcolombet at apple.com>> wrote: > > > The challenge is, AFAICT (which is not much, I admit), that > front-end warning types are statically handled using tablegen > representation. > > > They can also be added dynamically if necessary. See > DiagnosticsEngine::getCustomDiagIDAs I recall, after using these from experience, this approach doesn't actually properly handle things like -Werror "automatically." -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130716/bb7aba0e/attachment.html>
We had a similar problem with using LLVM on the GPU @ AMD as many times errors were not known until post-ISel/Resource Allocation. Our solution was to embed the errors in the resulting ISA and have the assembler/loader emit/error at that time. So this kind of API would be useful for more than just kernel development. Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Quentin Colombet Sent: Tuesday, July 16, 2013 5:21 PM To: LLVM Developers Mailing List Subject: [LLVMdev] [RFC] Add warning capabilities in LLVM. Hi, I would like to start a discussion about error/warning reporting in LLVM and how we can extend the current mechanism to take advantage of clang capabilities. ** Motivation ** Currently LLVM provides a way to report error either directly (print to stderr) or by using a user defined error handler. For instance, in inline asm parsing, we can specify the diagnostic handler to report the errors in clang. The basic idea would be to be able to do that for warnings too (and for other kind of errors?). A motivating example can be found with the following link where we want LLVM to be able to warn on the stack size to help developing kernels: http://llvm.org/bugs/show_bug.cgi?id=4072 By adding this capability, we would be able to have access to all the nice features clang provides with warnings: - Promote it to an error. - Ignore it. ** Challenge ** To be able to take advantage of clang framework for warning/error reporting, warnings have to be associated with warning groups. Thus, we need a way for the backend to specify a front-end warning type. The challenge is, AFAICT (which is not much, I admit), that front-end warning types are statically handled using tablegen representation. ** Advices Needed ** 1. Decide whether or not we want such capabilities (if we do not we may just add sporadically the support for a new warning/group of warning/error). 2. Come up with a plan to implement that (assuming we want it). Thanks for the feedbacks. Cheers, -Quentin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130717/8adc0d32/attachment.html>
Hi, Several weeks ago a prototyped a feature similar to what you're describing. I was experimenting to see how one might implement a feature like ICC's -vec–report feature in clang/llvm. My approach was to create an ImmutablePass which stores notes. I modified the loop vectorizer and the unroll pass to add notes when loops were vectorized or unrolled. On the clang side I add an OptReport to the pass manager and dump out the notes as diagnostics. It worked ok as a prototype but getting the source locations correct was a bit fragile. I've attached some patches in case you're interested. Paul From: Quentin Colombet <qcolombet at apple.com<mailto:qcolombet at apple.com>> Date: Tuesday, 16 July, 2013 8:21 PM To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> Subject: [LLVMdev] [RFC] Add warning capabilities in LLVM. Hi, I would like to start a discussion about error/warning reporting in LLVM and how we can extend the current mechanism to take advantage of clang capabilities. ** Motivation ** Currently LLVM provides a way to report error either directly (print to stderr) or by using a user defined error handler. For instance, in inline asm parsing, we can specify the diagnostic handler to report the errors in clang. The basic idea would be to be able to do that for warnings too (and for other kind of errors?). A motivating example can be found with the following link where we want LLVM to be able to warn on the stack size to help developing kernels: http://llvm.org/bugs/show_bug.cgi?id=4072 By adding this capability, we would be able to have access to all the nice features clang provides with warnings: - Promote it to an error. - Ignore it. ** Challenge ** To be able to take advantage of clang framework for warning/error reporting, warnings have to be associated with warning groups. Thus, we need a way for the backend to specify a front-end warning type. The challenge is, AFAICT (which is not much, I admit), that front-end warning types are statically handled using tablegen representation. ** Advices Needed ** 1. Decide whether or not we want such capabilities (if we do not we may just add sporadically the support for a new warning/group of warning/error). 2. Come up with a plan to implement that (assuming we want it). Thanks for the feedbacks. Cheers, -Quentin -------------- next part -------------- A non-text attachment was scrubbed... Name: opt_report_clang.diff Type: application/octet-stream Size: 4011 bytes Desc: opt_report_clang.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/71a835d7/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: opt_report_llvm.diff Type: application/octet-stream Size: 7219 bytes Desc: opt_report_llvm.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/71a835d7/attachment-0001.obj>
Hi Paul, Thanks for sharing your patches. This is interesting. Cheers, -Quentin On Jul 29, 2013, at 2:40 PM, Redmond, Paul <paul.redmond at intel.com> wrote:> Hi, > > Several weeks ago a prototyped a feature similar to what you're describing. I was experimenting to see how one might implement a feature like ICC's -vec–report feature in clang/llvm. My approach was to create an ImmutablePass which stores notes. I modified the loop vectorizer and the unroll pass to add notes when loops were vectorized or unrolled. > > On the clang side I add an OptReport to the pass manager and dump out the notes as diagnostics. It worked ok as a prototype but getting the source locations correct was a bit fragile. > > I've attached some patches in case you're interested. > > Paul > > > > From: Quentin Colombet <qcolombet at apple.com<mailto:qcolombet at apple.com>> > Date: Tuesday, 16 July, 2013 8:21 PM > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> > Subject: [LLVMdev] [RFC] Add warning capabilities in LLVM. > > Hi, > > I would like to start a discussion about error/warning reporting in LLVM and how we can extend the current mechanism to take advantage of clang capabilities. > > > ** Motivation ** > > Currently LLVM provides a way to report error either directly (print to stderr) or by using a user defined error handler. For instance, in inline asm parsing, we can specify the diagnostic handler to report the errors in clang. > > The basic idea would be to be able to do that for warnings too (and for other kind of errors?). > A motivating example can be found with the following link where we want LLVM to be able to warn on the stack size to help developing kernels: > http://llvm.org/bugs/show_bug.cgi?id=4072 > > By adding this capability, we would be able to have access to all the nice features clang provides with warnings: > - Promote it to an error. > - Ignore it. > > > ** Challenge ** > > To be able to take advantage of clang framework for warning/error reporting, warnings have to be associated with warning groups. > Thus, we need a way for the backend to specify a front-end warning type. > > The challenge is, AFAICT (which is not much, I admit), that front-end warning types are statically handled using tablegen representation. > > > ** Advices Needed ** > > 1. Decide whether or not we want such capabilities (if we do not we may just add sporadically the support for a new warning/group of warning/error). > 2. Come up with a plan to implement that (assuming we want it). > > > Thanks for the feedbacks. > > Cheers, > > -Quentin > > <opt_report_clang.diff><opt_report_llvm.diff>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/b458e880/attachment.html>