I'm still (as per another similar thread) a bit concerned this is working around a compiler optimizer bug - I'd love to see a standalone example of this behavior (that adding the inline keyword to an already inline/available definition is what's causing the inlining) so we can look at what the compiler might be doing wrong (& consider fixing that as the root cause instead of having to change every instance of this problem) - preferably an example without std::string/headers/etc (so, preprocessed and reduced).
But up to you folks maintaining libc++ whether this goes in of course, just my 2c. On Wed, Aug 3, 2016 at 5:23 AM Aditya Kumar via cfe-commits < cfe-commits@lists.llvm.org> wrote: > hiraditya added a comment. > > In https://reviews.llvm.org/D22782#504416, @EricWF wrote: > > > The change itself LGTM, although we probably want to inline the > forward/input iterator __init's as well. > > > > However I would like to see a small benchmark that demonstrates the > performance change. Please try and write the benchmark using Google > Benchmark. > > Some helpful links: > > > > - http://libcxx.llvm.org/docs/TestingLibcxx.html#building-benchmarks > > - http://github.com/google/benchmark > > > Sure, > We'll come up with a synthetic benchmark to expose performance > improvements. > > Thanks, > > > https://reviews.llvm.org/D22782 > > > > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
