[PATCH] Don't use ManagedStatic.

[Rui Ueyama]

Probably my fundamental question is that why we need a "success" for each
category. There are many types of errors which can be categorized, but to
me success is just success, and I don't see any need to distinguish them.

On Mon, Jun 8, 2015 at 8:50 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Mon, Jun 8, 2015 at 8:16 PM, Rui Ueyama <ruiu at google.com> wrote:
>
>> On Mon, Jun 8, 2015 at 7:45 PM, Sean Silva <chisophugis at gmail.com> wrote:
>>
>>> What is calling object::object_category so much that it can occupy 9% of
>>> the run time? If that code path is sufficiently common maybe it should just
>>> not be using "errors" in the first place.
>>
>>
>> Good point. There are many places in include/llvm/Object where we return
>> object_error::success. That seems the cause of this problem.
>>
>> Maybe we should remove object_error::success and use std::error_code
>> instead.
>>
>> Any objection?
>>
>
> I'm not sure that is the right solution (maybe it is, CC'ing Michael). We
> use the <system_error> API in many places in LLVM and I would like to make
> sure that we are not paying this cost anywhere. For example, we are also
> using ManagedStatic for BitcodeErrorCategoryType, which probably leads to
> similar problems. I'm having a hard time believing that this API got
> standardized if it is impossible to use with low overhead.
>
> E.g. I'm wondering why _object_error_category requires runtime
> initialization at all. The class is empty. So is error_category (its base
> class). It should just be a vptr with a relocation against it. With LTO,
> all calls to object::object_category should be inlined and fully constant
> folded.
>
> CC'ing Michael who knows more about this error handling API. Michael, do
> you know if there is a way to use this API that doesn't require runtime
> initialization of the error_category objects?
>
> -- Sean Silva
>
>
>>
>>
>>> Overall, just relying on thread-safe statics is preferable, but even
>>> then having so many non-inlined calls to this function in regular operation
>>> doesn't seem right.
>>>
>>>
>>> http://reviews.llvm.org/D10303
>>>
>>> EMAIL PREFERENCES
>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150608/da428107/attachment.html>