Worked with Sebastian Pop
Details
Diff Detail
Event Timeline
/me wonders what the perf difference when _LIBCPP_UNROLL_LOOPS is defined or not.
I think this (_LIBCPP_UNROLL_LOOPS) falls squarely into Chandler's request that we complain to him when the compiler generates sub-optimal code, instead of doing things like manually unrolling loops.
I think we should remove all the code in the ifdef: it looks to me like this code was left in from a previous "experiment", as it never gets executed unless one compiles the code with -D_LIBCPP_UNROLL_LOOPS, which seems wrong. Let's push this cleanup in a separate commit.
There are no uses of _LIBCPP_UNROLL_LOOPS in LLVM (other than the ones in <algorithm>.
Googling for _LIBCPP_UNROLL_LOOPS on github finds the ones in libc++, and no others.
I think I'll just take it out, and see what happens.
@mclow.lists
I can remove this and update this patch with the load hoisted, if this is okay.
This looks fine to me - though I wonder if the compiler can hoist *__first2 w/o us helping it.
libcxx/include/algorithm | ||
---|---|---|
1499 ↗ | (On Diff #79463) | I just realized that we can't do this. With this in place, we can't search a sequence of move-only types. |
libcxx/include/algorithm | ||
---|---|---|
1499 ↗ | (On Diff #79463) | Ok, I'll remove this change while pushing. I'll change the subject as well, because now this patch is just removing the unused code. |
libcxx/include/algorithm | ||
---|---|---|
1499 ↗ | (On Diff #79463) | Are we allowed to call __search on a type which is not copy-constructible? |