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

[Eric Christopher]

>> 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.

>>
>> a) Front end diagnostics - This is an area that needs some work to be
>> decent, but it involves the front end querying the back end for things
>> like register size, valid immediates, etc and should be implemented by
>> the front end with an expanded set of target queries. We could use
>> this as a way to solidify the backend api for the MS inline asm
>> support as well and use some of that when parsing GNU style inline
>> asm.
>
> Yes, I agree about this, too.  As an example, we had a discussion a few months ago about warning about over-aligned stack variables when dynamic stack realignment is disabled, and we agreed to move that warning into the frontend.  I keep poking at the frontend team every once in a while to get some help implementing that, but I haven't forgotten it.
>

*nod* This should be pretty easy to implement out of the front end at
a first thought - "if we're creating an alloca with an alignment
greater than the target and we've turned off dynamic realignment then
warn". The trick is getting the backend data for such things etc.

>>
>> b) Back end diagnostics - This is the stuff that the front end has no
>> hope of diagnosing. i.e. "ran out of registers", or "can't figure out
>> how to split this up into this kind of vector register". The latter
>> has always been a bit funny and I'm always unhappy with it, but I
>> don't have any better ideas. A unified scheme of communicating "help
>> help I'm being oppressed by the front end" in the backend would be, at
>> the very least, a step forward.
>>
>> Thoughts?
>
> I don't have any better ideas for this.  At least if we generalize the existing inline asm diagnostic handler, it will make it less of a special case.

Ah, the thoughts was an "in general", but if you'd had ideas I'd have
totally been up for them :)

-eric