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

[Hal Finkel]

----- Original Message -----
> From: "Tobias Grosser" <tobias at grosser.es>
> To: "Hal Finkel" <hfinkel at anl.gov>
> 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:34:40 PM
> Subject: Re: [PATCH] Add warning capabilities in LLVM (backend part), Take 2
> 
> 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. 

No, the overhead of having a map for functions to Decls should be in the noise. CGM already has a lot of state (including hash tables) already.

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

I think that we want Clang CodeGen to add SrcLoc metadata to loops (just like we do for inline asm). This will be better, and lower overhead, than trying to use debug info, and won't depend in having debug info enabled. We have the loop-id infrastructure now, thanks to the loop vectorizer work, so this should be straightforward at this point.

 -Hal

> 
> Cheers,
> Tobias
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory