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

[Eric Christopher]

>> I think this scheme could also work as a way of dealing with the
>> "Optimization Diary" sort of use that Hal is envisioning as well.
>
> I like "Optimization Diary" :)
>
> Obviously, we sometimes loose debug information on variables while optimizing, and so the trick is to make it degrade nicely. Nevertheless, I think that we can often be more expressive than just using a single location for everything. How about something like this:
>
>  - The message string is text but a single kind of markup is allowed: <debug/>, for example:
>      "We cannot vectorize <debug/> because <debug/> is an unfriendly variable"
>    (where the first will be replaced by text derived from a DIScope and the second from a DIVariable).
>
>  - The structure is this:
>     struct Msg {
>       const char *Message;
>       Function *F; // If nothing else, we can extract a useful name from here, hopefully.
>       SmallVector<DIDescriptor, 2> DIs; // Should be DIDescriptor* ?
>     };
>
> Then, in the backend, we can look for a DbgValueInst associated with the variable that we want (similar for scopes), and push a DIScope, DIVariable, etc. onto the array, one for every <debug/> in the message string. The frontend can then render these references in whatever way seems most appropriate (which may include things like making them into hyperlinks, doing some kind of source-code highlighting, etc.).
>

Yep, that's what I was going for. As a note you don't need to worry
about the Function and DIs as a DebugLoc has a scope and can be
traveled back to find a function that it's inside or any other
enclosing scope. Though I've just posted another message to the thread
with a design for a more informational set of callbacks that could be
used by individual passes. I don't have a good design off the top of
my head, but...

-eric

> Thanks again,
> Hal
>
>>
>> Keeping the separation of concerns around where the front end handles
>> diagnostics on what we'll call "source locations" is pretty
>> important,
>> however, I agree that not every warning can be expressed this way,
>> i.e. the stack size diagnostic. However, leaving the printing up to
>> the front end is the best way to deal with this and a generic
>> diagnostic engine would probably help for things like llc/opt where
>> the backend just deals with its input language - IR.
>>
>> The existing inline asm diagnostics are ... problematic and it would
>> definitely be nice to get a generic interface for them. Though
>> they're
>> actually separated into two separate cases where, I think, we end up
>> with our confusion:
>>
>> 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.
>>
>> 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?
>>
>> -eric
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory