[llvm-bugs] [Bug 36591] New: Missed optimization: static guard variable generated for empty virtual destructor

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36591

            Bug ID: 36591
           Summary: Missed optimization: static guard variable generated
                    for empty virtual destructor
           Product: new-bugs
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: arthur.j.odwyer at gmail.com
                CC: llvm-bugs at lists.llvm.org

Consider the following program:

struct Base {
    constexpr Base() = default;
    virtual int foo();
    // virtual ~Base() = default;
};
struct Derived : public Base {
    constexpr Derived() = default;
    virtual int foo() override;
};
Base& get_base() {
    static Derived d;
    return d;
}

This is a simplified version of the current idioms around `std::error_category`
and `std::pmr::memory_resource`, except that for now I have commented-out the
virtual destructor.
Notice that because `Derived d` is trivially destructible, no atomic guard
variable is generated to guard its construction with
__cxa_guard_acquire/__cxa_guard_release.

Now uncomment the defaulted virtual destructor of `Base`. The semantics of
`Derived d` have not changed: we are still expecting to call ~Derived by
non-virtual dispatch, and ~Derived is still known statically to be a no-op.
(And Derived has a vtable either way, too.) But now suddenly Clang decides to
generate an atomic guard variable!

I think Clang could do better here, and if it did, it would eliminate a lot of
atomic instructions in the critical path for things like `std::error_code{}`
and `std::pmr::new_delete_resource()`.

(Slightly different symptom, same bug, filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84411 .)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180303/0bfc6dad/attachment.html>