[libcxx-commits] [PATCH] D112152: [libc++] Unroll loop in std::find_if and define other std::find variants in terms of it

[Florian Hahn via Phabricator via libcxx-commits]

fhahn added inline comments.


================
Comment at: libcxx/include/__algorithm/find_if.h:90
+
 _LIBCPP_END_NAMESPACE_STD
 
----------------
Quuxplusone wrote:
> Idle thought: @fhahn's commentary makes me realize that this PR is uncomfortably adjacent to the ongoing LWG(?) debate over
> ```
> const char *first = "hello world";
> const char *last = std::ranges::find(first, std::unreachable_sentinel, '\0');
> ```
> The first question is, because `unreachable_sentinel` by definition can't be reached by incrementing `first` — does that mean that `[first, unreachable_sentinel)` lacks valid-range-ness in the same way as `[first, first-1)` or `[first, nullptr)` lacks valid-range-ness? in which case the above has UB?
> Related but perhaps orthogonally, does that mean that `find` in practice should be allowed to read from elements beyond the match as long as they're still in the provided range, e.g.
> ```
> int buf[100];  // uninitialized garbage
> buf[0] = 42; buf[1] = 43; buf[2] = 44;
> const char *last = std::find(buf, buf+100, 44);  // could this read buf[3] and thus have UB?
> ```
> I think this specific PR isn't doing anything new and dangerous //right now//, but the commentary about "vectorization" and "information that pointers are dereferenceable" and "better optimization" seems very scary to me.
That's an interesting point! I naively assumed that both start and end iterators need to be referring to a valid range. 

This observation is key to the vectorisation route I think, so if that won't hold in general then it might not be worth pursuing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112152