More consistent LTO diagnostic handling

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Sat Oct 24 17:20:52 PDT 2015


My preference would be to use the new diagnostic handler everywhere
and only switch to strings at the very last minute to maintain the C
api.

On 22 October 2015 at 19:18, Gao, Yunzhong
<yunzhong_gao at playstation.sony.com> wrote:
> Hi Rafael,
> With upstream r220608, lto_codegen_add_module() is switched to using the new diagnostic handler
> mechanism; however, there are quite a number of API calls in tools/lto/lto.cpp that are still passing
> around a std::string& in order to collect diagnostic messages (e.g., lto_module_create,
> lto_codegen_set_pic_model, etc.). Currently I can use lto_get_error_message() to query the error
> messages from all other API calls but just not from lto_codegen_add_module(). Is it possible to
> make the behavior more consistent? Maybe we will want to switch all other API calls to using the
> diagnostic handler too?
>
> One idea that I have:
> 1. add a std::string& reference member to the LTOCodeGenerator class, with setter/getter methods.
> 2. lto.cpp uses the new setter method to set the location of the diagnostic messages (e.g., during
>    lto_codegen_add_module) instead of passing around the std::string&.
> This idea has the potential to unify the diagnostic handling of lto_codegen_?? APIs such as
> lto_codegen_compile and lto_codegen_write_merged_modules, but is not helpful for non-codegen
> APIs such as lto_module_create. If a client uses lto_codegen_set_diagnostic_handler to specify
> a custom handler, those non-codegen APIs are still not affected.
>
> Suggestions? Advice?
>
> Many thanks in advance,
> - Gao


More information about the llvm-commits mailing list