[LLVMdev] [RFC] Add warning capabilities in LLVM.

[Redmond, Paul]

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>