[PATCH] Add warning capabilities in LLVM (backend part), Take 2

[Tobias Grosser]

On 12/18/2013 09:24 PM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Hal Finkel" <hfinkel at anl.gov>
>> To: "Tobias Grosser" <tobias at grosser.es>
>> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "llvm-commits" <llvm-commits at cs.uiuc.edu>,
>> reviews+D2376+public+8c083b1648e3e7b6 at llvm-reviews.chandlerc.com
>> Sent: Wednesday, December 18, 2013 2:21:22 PM
>> Subject: Re: [PATCH] Add warning capabilities in LLVM (backend part), Take 2
>>
>> ----- Original Message -----
>>> From: "Tobias Grosser" <tobias at grosser.es>
>>> To: "Quentin Colombet" <qcolombet at apple.com>
>>> Cc:
>>> reviews+D2376+public+8c083b1648e3e7b6 at llvm-reviews.chandlerc.com,
>>> "Chandler Carruth" <chandlerc at gmail.com>,
>>> "llvm-commits" <llvm-commits at cs.uiuc.edu>
>>> Sent: Wednesday, December 18, 2013 2:15:24 PM
>>> Subject: Re: [PATCH] Add warning capabilities in LLVM (backend
>>> part), Take 2
>>>
>>> On 12/18/2013 06:34 PM, Quentin Colombet wrote:
>>>>
>>>> On Dec 18, 2013, at 2:57 AM, Tobias Grosser <tobias at grosser.es>
>>>> wrote:
>>>>
>>>>> On 12/16/2013 06:41 PM, Quentin Colombet wrote:
>>>>>> Hi Tobias,
>>>>>>
>>>>>> On Dec 14, 2013, at 1:20 AM, Tobias Grosser <tobias at grosser.es>
>>>>>> wrote:
>>>>>
>>>>> I also used this interface to implement the first diagnostic in
>>>>> Polly (r197558).
>>>>>
>>>>> I also saw you started to submit patches to clang. For plugin
>>>>> authors, it would be amazing if a frontend could optionally
>>>>> register a callback that demangels function names. Like this,
>>>>> the
>>>>> plugin default printers could return something sensible.
>>>> Yes, we have to figure out how to do that.
>>>
>>> This file seems interesting:
>>>
>>> compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_itanium.cc
>>>
>>> It seems there is a demangler already accessible in modern C++ ABI
>>> libraries. What about providing a demangling interface that uses
>>> the
>>> C++
>>> itanium demangler as default (if available), falls back to just
>>> return
>>> the function name if no demangler is available and finally allows
>>> the
>>> frontend to provide its own demangler?
>>
>> I don't think that we want to demangle anything for this
>> functionality. Instead, we should keep a map between the AST
>> function objects (Decls) and the llvm::Function*, and use that to
>> get frontend information from the backend function values.
>
> n/m -- you're taking about the defaults in the backend?

Yes, the above demangler was meant as an optimistic guess in LLVM that 
could be overwritten by the frontend. While thinking about this I was
assuming the frontend would also have a stateless demangler, so most 
likely clang would not need to overwrite anything.

Your proposal of a map sounds interesting. Would creating and 
maintaining such a map cause memory overhead and slow down the code 
generation? In the end, the error reporting is an exceptional feature so 
always paying for it may not be what we want.  I am not involved enough 
in clang to judge which approach is better. If I can pass a function 
pointer to this feature and get a nice name back, I am happy.

Another point that may come up is printing of debug information. 
However, we can see later how this could be handled.

Cheers,
Tobias