[Lldb-commits] [PATCH] D154542: Further refinements on reporting interruption in lldb

[Alex Langford via Phabricator via lldb-commits]

bulbazord added inline comments.


================
Comment at: lldb/include/lldb/Core/Debugger.h:455-456
+    InterruptionReport(std::string function_name, std::string description) :
+        m_function_name(function_name), 
+        m_description(description),
+        m_interrupt_time(std::chrono::system_clock::now()),
----------------
jingham wrote:
> bulbazord wrote:
> > jingham wrote:
> > > bulbazord wrote:
> > > > To avoid some unnecessary copies
> > > > 
> > > > Could also do what Ismail is suggesting.
> > > This is a local that is copied to an ivar and never used again.  Do I really have to put move in there explicitly for the optimizer to know it can reuse the value?
> > Yes. I created a simple example on Godbolt: https://godbolt.org/z/G4ej76Enn
> > 
> > Observe that the constructor in the example invokes the `std::string` copy constructor. Add a `std::move` and it then invokes the move constructor.
> Thanks for the example, that was interesting.  
> 
> Note however that in your example, you the flags you specified were `-std=c++17` so that was an unoptimized build.  That's expected, unoptimized builds are supposed to be as literal as they can be.  If you instead use the same example with `-std=c++17 -O3` you won't see any copy constructors.  I don't 100% mind putting this std::move in, but it seems noisy to decorate up your code with hints that the optimizer can figure out on its own.
You're right that I did not consider higher optimization levels there. That being said, I believe this is a matter of language semantics and not optimization level. I've created a slightly more complex example to illustrate: https://godbolt.org/z/naMTcd7Ev

In this other example, I have passed `-O3`. You'll notice that in the emitted constructor code there are 2 calls to `operator new`. If you add `std::move` for both of the parameters of the constructor, both of these allocations go away and the generated code becomes ~60% smaller. Even with optimization involved, the compiler can only optimize so much without breaking semantics.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154542/new/

https://reviews.llvm.org/D154542