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

[Micah Villmow]

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>