Dead code not optimized away by the compiler?

[velvia]

Hi,

With the Intel Compiler version 16.0.1 on OSX, the following code

#include <cstdio>
#include <cstdlib>
#include <new>
#include <type_traits>

template <typename T>
class Test {
 private:
  T* data_;

 public:
  Test(int n);
  ~Test();
};

template <typename T>
Test<T>::Test(int n) {
  if (std::is_pod<T>::value) {
    data_ = new T;
  } else {
    data_ = static_cast<T*>(::operator new(n * sizeof(T)));
    for (int i{0}; i < n; ++i) {
      new (data_ + i) T{};
    }
  }
};

template <typename T>
Test<T>::~Test() {
  if (std::is_pod<double>::value) {
    delete[] data_;
  } else {
    ::operator delete(data_);
  }
};

int main(int argc, const char* argv[]) {
  Test<double> x{10};

  return 0;
}

compiled with

icpc -std=c++11 -O3 -xHost -ansi-alias -fno-exceptions -DNDEBUG -opt-report=3 main.cpp -o main

produces an optimization report where it is clear that the call to ::operator new is still present in the optimization report although it is clear that at compile time, we now that this code is dead code.

INLINE REPORT: (main(int, const char **)) [1] main.cpp(37,40)
  -> INLINE (MANUAL): (38,18) Test<double>::Test(Test<double> *, int)
    -> EXTERN: (19,20) operator new[](size_t)
    -> INLINE (MANUAL): (23,12) operator new(size_t, void *)
  -> INLINE (MANUAL): (40,3) Test<double>::~Test(Test<double> *)
    -> EXTERN: (31,5) operator delete[](void *)

I suspect this is an optimization bug of the Intel compiler. But it seems that the assembly does not contain any code related to operator new.

Best regards,

Francois

[Chang-Sun_L_Intel]

Thanks for your question! Inlining runs before most other optimizations in the compiler. It replaces a function call (in this case, operator new(size_t, void *)) with the function body. This instance of the call will then no longer exist in the generated code. The compiler is reporting that this optimization is happening.

After inlining, the rest of the optimizations, including dead code removal and loop optimizations, are applied. I think what you may be getting at, is that the compiler is not reporting whether it removes the loop or not. This is true---the compiler's optimization report is geared towards reporting optimizations that have a high impact on the execution performance, or that may need the user to assist in some way, such as removing pointer aliases or aligning data. In the case of inlining, the user may want to control it, to reach a code size target, improve performance, or improve debuggability. Dead code removal, on the other hand, is kind of a normal process in the compiler that can operate without interaction from the user. 

[velvia]

Hi Chang. Thanks for your clear reply.

[TimP]

I was under the impression that the policy of not reporting dead code removal was set long ago at request of some customers.  It could greatly clutter up reports.

[velvia]

Hi Tim,

I was worried because I thought the dead code was not removed. Moreover, I've already seen some DEAD keyword in the report file and I thought that all dead code was flagged.

But I understand that flagging all dead code by default would clutter any report involving "generic code" such as the STL. Thanks to both of you, I have a better understanding of the reason of this choice.