[PATCH] Don't use ManagedStatic.

Sean Silva chisophugis at gmail.com
Mon Jun 8 20:50:02 PDT 2015


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/d7dc9cc3/attachment.html>


More information about the llvm-commits mailing list