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

[Quentin Colombet]

Hi,

Compared to my previous email, I have added Hal’s idea for formatting the message and pull back some idea from the "querying framework”.
Indeed, I propose to add some information in the reporting so that a front-end (more generally a client) can filter the diagnostics or take proper actions.
See the details hereafter.

On Jul 22, 2013, at 2:25 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <echristo at gmail.com> wrote:
> >> This is pretty much the same as what Quentin proposed (with the addition of the enum), isn't it?
> >>
> >
> > Pretty close yeah.
> >
> 
> Another thought and alternate strategy for dealing with these sorts of things:
> 
> A much more broad set of callback machinery that allows the backend to
> communicate values or other information back to the front end that can
> then decide what to do. We can define an interface around this, but
> instead of having the backend vending diagnostics we have the callback
> take a "do something with this value" which can just be "communicate
> it back to the front end" or a diagnostic callback can be passed down
> from the front end, etc.
> 
> This will probably take a bit more design to get a general framework
> set up, but imagine the usefulness of say being able to automatically
> reschedule a jitted function to a thread with a larger default stack
> size if the callback states that the thread size was N+1 where N is
> the size of the stack for a thread you've created.
> 
> FWIW, *this* is what I was trying to get across. Not that it wouldn't be a callback-based mechanism, but that it should be a fully general mechanism rather than having something to do with warnings, errors, notes, etc. If a frontend chooses to use it to produce such diagnostics, cool, but there are other use cases that the same machinery should serve.

I like the general idea.

To be sure I understood the proposal, let me give an example.

** Example **
The compiler says here is the size of the stack for Loc via a “handler” (“handler" in the sense whatever mechanism we come up to make such communication possible). Then the front-end builds the diagnostic from that information (or query for more if needed) or drops everything if it does not care about this size for instance (either it does not care at all or the size is small enough compared to its setting).

** Comments **
Unless we have one handler per -kind of - use, and I would like to avoid that, I think we should still provide an information on the severity of the thing we are reporting and what we are reporting.
Basically:
- Severity: Will the back-end abort after the information pass down or will it continue (the boolean of the previous proposal)?
- Kind: What are we reporting (the enum from the previous proposal)?

I also think we should be able to provide a default (formatted) message, such that a client that does not need to know what to do with the information can still print something somehow useful, especially on abort cases.
Thus, it sounds a good thing to me to have a string with some markers to format the output plus the arguments to be used in the formatted output.
Hal’s proposal could do the trick (although I do not know if DIDescriptor are the best thing to use here).

** Summary **
I am starting to think that we should be able to cover the reporting case plus some querying mechanism with something like:
void reportSomehtingToFEHandler(enum Reporting Kind, bool IsAbort, <some information>, const char* DefautMsg, <pointer to a list of args to format in the defautMsg>)

Where <some information>  is supposed to be the class/struct/pointer to the relevant information for this kind. If it is not enough the FE should call additional APIs to get what it wants.

This looks similar to the “classical” back-end report to front-end approach, but gives more freedom to the front-end as it can choose what to do based on the attached information.
I also believe this will reduce the need to expose back-end APIs and speed up the process.
However, the ability of the front-end (or client) to query the back-end is limited to the places where the back-end is reporting something. Also, if the back-end is meant to abort, the FE cannot do anything about it (e.g., the stack size is not big enough for the jitted function).
That’s why I said it cover “some" querying mechanism.

** Concerns **
1. Testing.

Assuming we will always emit these reports, relying on a front-end to filter out what is not currently relevant (e.g., we did not set the stack size warning in the FE), what will happen when we test (make check) without a front-end?
I am afraid we will pollute all tests or we will have some difficulty to test a specific reporting.

2. Regarding a completely query based approach, like Chris pointed out, I do not see how we can report consistent information at any given time. Also, Eric, coming back to your jit example, how could we prevent the back-end to abort if the jitted is too big for the stack?

3. Back to the strictly reporting approach where we extend the inlineasm handler (the approach proposed by Bob and that I sketched a little bit more), now looks similar to this approach expect that the back-end chooses what it is relevant to report and the back-end does not need to pass down the information.
The concern is how do we easily (in a robust and extendable manner) provide a front-end/back-end option for each warning/error?


Thoughts?

Cheers,

-Quentin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130722/6f842fe4/attachment.html>