[PATCH] Add warning capabilities in LLVM (backend part), Take 2
hfinkel at anl.gov
Wed Dec 18 12:21:22 PST 2013
----- 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:
> It seems there is a demangler already accessible in modern C++ ABI
> libraries. What about providing a demangling interface that uses the
> itanium demangler as default (if available), falls back to just
> 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.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits