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

Eric Christopher echristo at gmail.com
Mon Jul 22 14:21:05 PDT 2013


On Mon, Jul 22, 2013 at 1:26 PM, Eric Christopher <echristo at gmail.com> wrote:
>>> Have the backend vend diagnostics, this can be done either with a set
>>> of enums and messages like you mentioned, or just have a message and
>>> location struct ala:
>>>
>>> struct Msg {
>>>   const char *Message;
>>>   Location Loc;
>>> };
>>>
>>> that the consumer of the message can use via a handler.
>>
>> When the consumer is clang, it's important that we have diagnostic groups to control the warnings, so the enum is important.  We don't want to be comparing the message strings to decide whether a particular warning is an instance of -Wstack-size (for example).
>>
>
> I think, in this case, that I'd want the registration function to
> handle the "give me these sorts of warnings" rather than it be a part
> of the message. I.e. you'd register for each class of warnings out of
> the backend maybe?
>
>>
>> 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.

Thoughts?

-eric




More information about the llvm-dev mailing list