r194288 - If a linkonce_odr dtor/ctor is identical to another one, just rauw.

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Nov 12 11:01:25 PST 2013


> struct derived: base {
>   ~derived();
> };
>
> derived::~derived() = default;

It fires on

--------------------------------
struct base {
  ~base();
};
base::~base() {}
struct derived : base {
  ~derived();
};
derived::~derived() = default;
-----------------------

> Yet when I wrote this:
>
> struct base {
>   virtual ~base() { func(); }
> };
>
> struct derived : base {
> };
>
> int main() {
>   derived d;
> }
>
> the call stack at "func()" did not include a derived dtor - perhaps this is
> an existing optimization not related to your change, then?

No, it is exactly this optimization. The derived destructor is this
case has no special work to do. Its body would have been

define linkonce_odr void @_ZN7derivedD2Ev(%struct.derived* %this)
unnamed_addr #1 align 2 {
  %1 = alloca %struct.derived*, align 8
  store %struct.derived* %this, %struct.derived** %1, align 8
  %2 = load %struct.derived** %1
  %3 = bitcast %struct.derived* %2 to %struct.base*
  call void @_ZN4baseD2Ev(%struct.base* %3)
  ret void
}

Noet that this optimization already existed. It was just used in cases
where the destrutor had strong linkage. What the change to use rauw
made possible is for the optimization to kick in in more situations,
like linkonce_odr.

>> LLVM also does'n implement replacing the pointers in the vtables.
>
>
> But it doesn't look like your optimization was happening with vtables
> either, at least not in my tests. When the destruction is actually virtual
> (delete base_ptr_to_derived_obj) I see both base and derived dtors on the
> stack.

Sorry, can you provide a test?

>>
>> We
>> probably could (and should) implement an optimization in llvm so that
>> a trivial unnamed_addr function that just calls another is replaced
>> with an alias or replaced with the callee.
>
>
> Probably, but I'm not sure that's what I'm asking about.
>
> I'm asking about the simple cases of known-derived object destruction
> skipping the derived dtor (such as the example above with "derived d;" in
> main). But as I said - maybe that's a different optimization that's not
> related to your change?

Depends on the linkage of the destructor. If it was not weak, we would
have produced an alias already.

Cheers,
Rafael



More information about the cfe-commits mailing list